Skip to content

Conversation

rapier1
Copy link
Owner

@rapier1 rapier1 commented Sep 29, 2025

There are 2 main changes since 18.7.0.

RFC 8305 aka Happy Eyeballs
This is for use on dual stack systems meaning that they have both IPv4 and IPv6 TCP stacks. When enabled this option will try to connect to the target over both IPv4 and IPv6 with preference given to IPv6. This preference is created by giving IPv6 a 250ms head start over the IPv4 connection. Users can change this with the HappyDelay option. The first connection that completes successfully will be used. Any outstanding connection attempts will be closed. As of version 18.7.1 this option should be considered somewhat experimental.
usage:
-oHappyEyes=[Yes|No] will enable Happy Eyeballs. The default is no.
-oHappyDelay=[N] where N is a positive integer expressed in
milliseconds. The default value of 250ms is
suggested by RFC 8305.

FIPS Mode and Parallel Ciphers
Using HPN-SSH in operating systems working in FIPS mode (e.g. RHEL with FIPS enabled) preclude the use of parallel ciphers. This is because the parallel AES-CTR implementation is not FIPS certified and will cause FIPS to exit with an error when loaded. In the case of the parallel ChaCha20 cipher the algorithm itself has not been FIPS certified and no implementation of ChaCha20 should be allowed in FIPS mode. We suggest the use of the AES-GCM cipher when operating under FIPS mode for optimal performance. This is behaviour is not user adjustable.

Minor Changes
The 64bit XOR method used in AES-CTR-MT was causing undefined behaviour. We have reduce the maximum bit size of an XOR to 32 bits until we develop a better XOR method. XORing is one of those things that can have an outsized impact on performance so please let us know if you see any noticeable performance hit. Also, if anyone wants to solve the XOR issue for us we'd love the help. Various changes have been made to the CI system on github and we've changed some minor parts of the regression test suites.

rapier1 added 30 commits May 21, 2025 16:52
This is a patched based on one written by
Kim Minh Kaplan and submitted to OpenSSH in 2018.
This implements *some* features of RFC 8305 but,
significnatly, does not do asynchronous DNS queries.
It is currently only implemented for direct and proxy
connections as found in sshconnect.c. This is the first
version of the patch and is not in its final form. Eventually
the RFC 8305 methods will be moved their own file and the
necessary methods made public for use elsewhere in the
code base.
This is a patched based on one written by
Kim Minh Kaplan and submitted to OpenSSH in 2018.
This implements *some* features of RFC 8305 but,
significnatly, does not do asynchronous DNS queries.
It is currently only implemented for direct and proxy
connections as found in sshconnect.c. This is the first
version of the patch and is not in its final form. Eventually
the RFC 8305 methods will be moved their own file and the
necessary methods made public for use elsewhere in the
code base.

Note: the regression test is of dubious value as the
tests happen on localhost. It's mostly to ensure that
any connection can take place rather than testing the
functionality of the imeplementation. This will likely
change in future versions.
The makes the happy_eyeballs function public so we can use it elsewhere
if necessary. It also reduces the code complexity in sshconnect.c.
I also forgot to add those files to the commit.
The default IPQoS for SSH had changed from
interactive = lowdelay
bulk = throughput
to
interactive = af21
bulk = cs1

The result of this being that in test scenarios, where we used
tc qdisc to insert delay on IPv6, the IPv4 connections ended up
having the same effective delay as the IPv6. This meant that we'd
always end up using the IPv6 connection even though IPv4 was
not being delayed. I don't really understand DSCP enough to undertand
why this is happening but this might be a test artifact. In any case,
being that both IPv4 and IPv6 had the same effective delay the IPv6
connection would always end up winning the race because of the
250ms pause between the IPv6 and IPv4 attempts.

This commit stil lhas too many debug statements in it but
it works for testing.
This is a runtime option to specify the delay between
starting the IPv6 connection and the IPv4 connection.
The default is 250ms as per RFC 8305. This must be a
positive integer. 0 or negative values will be rewritten
to a value of 1ms.

Updated documentation to include HappyEye options.
We were previously resolving the issue by changing the defaults
for all connections. We now only change the QoS defaults if
we are using RRFC 8305.
While the AES-CTR algorithm is FIPS certified this implementation
is not. This causes FIPS to automatically error out when the aes-ctr-mt
cipher is loaded. This can be resolved by using the DisableMTAES options but
this requires the user to be aware of it and know why FIPS is erroring out.
This will automatically detect if FIPS mode is enabled on fedora variants that
write to /proc/sys/crypto/fips_enabled. In the event this entry doesn't exist
or that we can't read from it we assume that FIPS mode is not enabled and
we allow parallel ciphers.

This does not apply to the ChaCha20 cipher as the algorithm itself is not
FIPS validated and it's up to the admin to make sure it's not being
offered as an option.
These fixes include pushing the SCP resume tests to their
own test script. They don't work under windows so we now
skip them.

It also includes a change to the XOR function in cipher-ctr-mt.
We were trying to do a 64 bit XOR but it was causing UBs in
some of the CI tests. Until we have that resolved we need to
stick with 32 bit XORs. Which we *really* need to resolve.

The last major thing was that valgrind was consistently hanging on
the rekey test (valgrind-5). Using the --fair-sched=try option
for thread serialization in valgrind resolves that issue.
This came up under CI testing with MacOS.
Tabs not allowed in indents.
changes requested from review.
fips_enabled() in misc.c originally had debug messages that
reported if the parallel ciphers were enabled or not. This
was the wrong place for those messages. They should be in
session.c and ssh.c when we check the FIPS status.

Also, the function had unclear variable names. These were
updated to be more descriptive.
Disable the parallel AES-CTR cipher under FIPS mode.
We should only need to change the IPQoS options for the client
side to support RFC 8305.
I used the new DSCP values from the 10.1 branch
instead of the 10.0 current. Annoying mistake
@rapier1 rapier1 requested a review from dorrellmw September 29, 2025 19:42
@rapier1 rapier1 added the Release New Release label Sep 29, 2025
Copy link
Collaborator

@dorrellmw dorrellmw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All commits approved through prior PRs or through direct review.

@rapier1 rapier1 merged commit 1f58137 into master Sep 30, 2025
167 of 169 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Release New Release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants