Re: TLS 1.3 and SNI; test script included

Since I use getmail with gmail this result is unsolicited, however I'll
contribute as my results differ:

[fahnoe@sprite tmp]$ cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)

[fahnoe@sprite tmp]$ python --version
Python 2.7.5

[fahnoe@sprite tmp]$ ./test-imap.py imap.gmail.com
Traceback (most recent call last):
  File "./test-imap.py", line 11, in <module>
    ssl_version=ssl.PROTOCOL_TLS, ca_certs=None,
AttributeError: 'module' object has no attribute 'PROTOCOL_TLS'


--Larry

On Fri, Feb 8, 2019 at 10:10 PM Charles Cazabon <
[email protected]> wrote:

> Daniel Kahn Gillmor <[email protected]> wrote:
> > >
> > > And the server says "wtf, never heard of that domain, I'm
> > > *mail*.isp.example.net" because that's the only TLS cert and domain
> it's
> > > been configured for.  Server drops the connection with an error.
> >
> > That itself smells like a bad decision on the server side (a reasonable
> > server that doesn't have a matching certificate should probably go ahead
> and
> > use the same certificate it would have used without any SNI).
>
> Using that argument means the problem shouldn't have occurred in the first
> place - breaking connections when TLS 1.3 is in use and SNI isn't supplied
> is
> "a bad decision on the server side" for Gmail -- yet here we are.
>
> I *could* just say "report this bug to Gmail", but we all know they don't
> care, 900-pound-gorilla etc.
>
> > And the user in this story is in an unsafe configuration in the first
> place
> > because of the lack of certificate checking.
>
> I'm not sure why you keep adding certificate checking into this argument.
> Going from not supplying SNI at all to supplying SNI by default could break
> things regardless of whether certificate checking is in use or not; that's
> what I'm worried about.
>
> I am *not* keen on adding another abstruse configuration option to getmail
> (use_sni) to complicate its SSL configuration options even more which most
> users will not understand and will just cargo-cult their way through based
> on
> random forum postings ("try setting use_sni=True", "no, try setting it to
> False").  But neither am I keen on breaking working configs for getmail
> users
> because getmail suddenly starts sending an SNI value that their mail server
> doesn't understand or doesn't like.
>
> So if I'm going to make getmail send SNI whenever the underlying Python and
> OpenSSL versions support it, I need to know it's NOT breaking connections
> with
> previously-working configs.
>
> As such, here's a test script.  Anyone who is interested in this issue,
> please
> run it with the IMAP server to connect to as a first argument (and you can
> supply port as a second argument if you don't want the default 993).  It
> will
> make two connections to the IMAP server (without logging in), one using SNI
> and one without, and then report on stdout/stderr:
>
>   (a) what server it connected to
>   (b) whether either or both connections failed
>   (c) what TLS cipher/protocol was negotiated
>   (d) whether it got different SSL certificates from the server between the
>       two connections.
>
> Example for imap.gmail.com:
>
>   $ ./test-imap.py imap.gmail.com
>   Connecting to imap.gmail.com:993
>   No SNI - got cipher ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
>   SNI - got cipher ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
>   Different certs for no-SNI and SNI:
> d5129635a050f63dd607ffa9271eefaab597c0975809765dad253973fc554d25 vs
> 1c971dad98db354df4c1b93aefd0098dbc17b62f11a9e7bdc0d438076889836d
>
> (The script will report if TLS 1.3 or SNI is not supported by your
> Python/OpenSSL combination).
>
> I'd like to see results for a selection of IMAP servers current getmail
> users
> are currently using, not just Gmail, which I can test from here ;)  Please
> post the output to the list.
>
> If there's a reasonable number of reports and it doesn't show connections
> breaking when SNI is in use, I'll consider making the change.
>
> > > Cue very unhappy getmail user, who had a working config, upgraded, and
> now
> > > can't retrieve his mail.
> >
> > iiuc, all gmail users are currently in exactly this position if they
> upgrade
> > to OpenSSL 1.1.1 and leave TLS 1.3 enabled.
>
> The difference there is that I didn't do anything to the users; *Google*
> broke
> their working setup.  It's completely different if something *I* do breaks
> working getmail configurations.
>
> Charles
>
> --
> -----------------------------------------------------------------------
> Charles Cazabon
> GPL'ed software available at:               http://pyropus.ca/software/
>
> --------------------------------------------------------------------------------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]



-- 
Larry Fahnoe, Fahnoe Technology Consulting, [email protected]
           Minneapolis, Minnesota       www.FahnoeTech.com