Royce Williams

Looks right to me -- all four values for 512, 1024, and 2048.

That would yield: ``` -dh448 -dh511 -dh512 -dh513 -dh576 -dh704 -dh767 -dh768 -dh769 -dh832 -dh960 -dh1023 -dh1024 -dh1025 -dh1088 -dh1984 -dh2047 -dh2048 -dh2049 -dh2112 -dh4032 -dh4095 -dh4096 -dh4097 -dh4160 -dh8128...

Works for me. :)

I've got some overdue deliverables elsewhere that have to come first, but may be able to pick this up in the next week or two, especially since you've given me...

Definitely seems to be server-side. My instance of testssl.sh is using static SSLv3-enabled OpenSSL, and I'm able to successfully detect SSLv2 and SSLv3 on public servers known to be using...

Good question - OK, if it's the same port (1003), I get the same result.

Apologies - I was both unclear and also didn't realize the port mapping. To clarify, ssl-v3:1003 is not responding for SSL/TLS at all. When I tried ssl-v2:1003, that also failed...

Interesting related refs: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ https://tools.ietf.org/html/draft-rescorla-tls-esni https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf https://news.ycombinator.com/item?id=16565368 https://huitema.wordpress.com/2017/09/12/cracking-the-sni-encryption-nut/

I know that the stated purpose of the Rust implementations is to be placeholders - but with an eye towards future multi-platform support, keeping the soft implementations available for porting...

That sounds like a great approach!