> When I link posttls-finger with the OpenSSL 1.1.1 library, I see: Just in case for reference, one can reproduce all this with 1.1.1 s_client. Below case is -starttls smtp -noservername. "Fun" part is that OU for the self-signed certificate reads "No SNI provided; please fix your client." Another "fun" part is that they don't seem to be concerned with SNI value, it can be literally whatever.
> posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25 > CommonName invalid2.invalid > posttls-finger: certificate verification failed for > gmail-smtp-in.l.google.com[173.194.66.26]:25: > self-signed certificate > posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25: > subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid > posttls-finger: Untrusted TLS connection established to > gmail-smtp-in.l.google.com[173.194.66.26]:25: > TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits) Below case is -starttls smtp -tls1_2 [with of without servername]. > The same command with OpenSSL 1.1.0 yields (no CAfile/CApath > so authentication fails where it would typically succeed): > > posttls-finger: certificate verification failed for > gmail-smtp-in.l.google.com[173.194.66.27]:25: > untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign > posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25: > subject_CN=gmail-smtp-in.l.google.com, > issuer_CN=Google Internet Authority G3, > posttls-finger: Untrusted TLS connection established to > gmail-smtp-in.l.google.com[173.194.66.27]:25: > TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits) > > This is a substantial behaviour change from TLS 1.2, and a rather > poor decision on Google's part IMHO, though I'm eager to learn why > this might have been a good idea. > > In the mean-time, Richard's objection to automatic TLS 1.3 use > after shared-library upgrade is starting to look more compelling? Question is what would be users' expectation. If we arrange it so that application compiled with 1.1.0 simply won't negotiate 1.3, then would it be reasonable of them to expect that it will start working if they simply recompile application? I.e. without changing application code! But in such case it wouldn't actually help for example this case, but only make things more confusing. I mean you end up with "all I wanted 1.3 and now it doesn't work at all". I'd say that it would be more appropriate to make user ask "I want 1.3 but don't get it, why? it keeps working with 1.2 though." With this in mind, wouldn't it be more appropriate to simply not offer 1.3 capability if application didn't provide input for SNI? _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project