[RESOLVED] Email Client issue

[couttsj]

I just received word that my ESP (Email Service Provider) is migrating to a Gmail platform. That means trouble for me as Gmail enforces TLS. So I have had to divert my attention to addressing this particular issue, as my current email client (JACMail) does not support TLS. I had a feeling that something like this would pop up, so I have been working at developing code for TLS 1.3.

Gmail says that it supports TLS 1.3, using TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. Unfortunately, it doesn't say what curves it accepts. In a Google Cloud page it says that TLS 1.2 uses "secp256r1", but TLS 1.3 uses x25519. Unfortunately, a footnote at the bottom says "TLS 1.3 is not yet finalized", which suggests that the article is not current. My OS (Win 8.1) does not support x25519.

Does anyone know what Elliptical curves Gmail supports?

J.A. Coutts

[wqweto]

Does anyone know what Elliptical curves Gmail supports?

Which protocol on which port?

Webmail is served by completely different servers than SMTP, POP3 or IMAP -- all different server farms.

Edit: Btw, you could use OS built-in Schannel/SSPI as well for TLS support for your email client like "normal" email clients do :-))

cheers,
</wqw>

[couttsj]

Which protocol on which port?

Webmail is served by completely different servers than SMTP, POP3 or IMAP -- all different server farms.

Edit: Btw, you could use OS built-in Schannel/SSPI as well for TLS support for your email client like "normal" email clients do :-))

cheers,
</wqw>

SMTP - Port 587
POP3 - Port 995
That is the only information that I have been provided so far. Webmail is accessed through the browser, which may be my only option until I can sort this thing out.

J.A. Coutts

PS. No mention on whether port 465 is to be supported.

[wqweto]

All of these gmail endpoints support secp256r1 in ClientHello w/ TLS 1.3 incl. the STARTTLS one on port 587

Edit: The logs were irrelevant. . .

The weird thing is that if X25519 is missing w/ only secp256r1 in ClientHello all of the endpoints issue a spurious HRR confirming the same secp256r1. . . after which handshake continues as normal.

Either a glitch in BoringSSL they are using or artefact of some aggresive TLS connection caching or (hardware) acceleration.

cheers,
</wqw>

[couttsj]

All of these gmail endpoints support secp256r1 in ClientHello w/ TLS 1.3 incl. the STARTTLS one on port 587

Edit: The logs were irrelevant. . .

The weird thing is that if X25519 is missing w/ only secp256r1 in ClientHello all of the endpoints issue a spurious HRR confirming the same secp256r1. . . after which handshake continues as normal.

Either a glitch in BoringSSL they are using or artefact of some aggresive TLS connection caching or (hardware) acceleration.

cheers,
</wqw>

Thanks wqweto;
I was hoping that was the case, as it will make my job easier. Things are confusing enough without having to dive back into TLS 1.2. The Client Handshake Request certainly is a strange one, but I have come to expect just about anything with this stuff.

J.A. Coutts
BTW: Simple Connection program to port 465 worked first try!

[wqweto]

Either a glitch in BoringSSL they are using or artefact of some aggresive TLS connection caching or (hardware) acceleration.

Ooops, there is no glitch in gmail's servers and secp256r1 group is working perfectly fine for ECDHE.

After modding the TLS client for this particular test it was sending X25519 public key in key_share extension but was advertising only secp256r1 in supported_groups extension -- yikes!

No wonder the server responded with HRR in a "get your act together" fashion :-))

Btw, here is an https server (written in Apple's Swift) that rejects X25519 and demands secp256r1 -- swifttls.org

cheers,
</wqw>