Interesting! And concerning. I'd definitely care about this too. Just as another data point, I checked one of my apps that serves from both a custom domain (https://brid.gy/) and appspot (https://brid-gy.appspot.com/), and Qualys's SSL Labs test shows that the appspot subdomain is still happily supporting traditional IP-based SSL, without SNI.
- https://www.ssllabs.com/ssltest/analyze.html?d=brid%2dgy.appspot.com&s=2607%3af8b0%3a4005%3a808%3a0%3a0%3a0%3a2014&hideResults=on - https://www.ssllabs.com/ssltest/analyze.html?d=brid.gy&s=2001%3a4860%3a4802%3a32%3a0%3a0%3a0%3a15&hideResults=on&latest On Tuesday, July 28, 2020 at 5:07:30 AM UTC-7 [email protected] wrote: > We have a large fleet of *U-Blox* IoT modem-equipped devices out there, > calling in to our backend on AppEngine, using SSL to <ourappname>. > appspot.com (we don't have any custom SSL cert or managed cert). > > Up until May 26 or so this year this has worked fine, after that some > endpoints started failing the SSL handshake, and the problem became worse > and worse until the entire fleet was disabled. > > U-Blox managed to trace it to a failing SSL negotiation, and that their > modems don't support the SSL SNI (Server Name Identification) option, which > is required normally to differ between certs on a server that has multiple > certs on the same IP. > > Sure enough, I checked with openssl s_client -noservername and it fails to > appspot.com now -* it doesn't provide the normal default cert of > *.appspot.com <http://appspot.com> anymore* when no SNI is given (just > the No SNI provided; please fix your client. message). > > I didn't find anything in the AppEngine release notes about this change. > > Now, this is a tricky because yes, SNI has been around since 2002 and I > think it's even mandatory in TLSv1.3. On the other hand, there must be > hundreds of thousands of U-Blox modems out there that doesn't support this, > and the companies that have built IoT products around AppEngine and U-Blox > (like us) will start to see their fleets fail. > > *Would it be possible to re-instate a default handling of the SSL > endpoints on appspot.com <http://appspot.com> to provide a default cert of > *.appspot.com <http://appspot.com> ? * > > We had to go non-encrypted as a panic work-around, which is obviously not > desirable. > > Another work-around is to purchase a completely separate IP and custom SSL > cert; this would remove the semantical requirement of SNI but it would be > helpful to confirm if there would still be a technical requirement for it > due to the way the AppEngine SSL endpoints are configured in that case. > > Best regards > /Bjorn > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/a08842e6-87d3-4428-bafd-971d93d2b7f4n%40googlegroups.com.
