I have SNI extension disabled with -Djsse.enableSNIExtension=false and SSLv3 disabled with sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2". This should just be vanilla TLS.
Peter On 11/11/14, 10:12 PM, "Konstantin Kolinko" <knst.koli...@gmail.com> wrote: >2014-11-12 0:03 GMT+03:00 Peter Robbins <peter.robb...@jamfsoftware.com>: >> Hi there, >> I’m running into an issue with fully-qualified domain names and https >> using Tomcat 8 and JDK 8. >> Tomcat version: 8.0.14 >> JDK Version: 1.8.0_25OS: Mac OS X 10.10 >> >> If you include the trailing dot in a request over https, the TLS >>handshake >> will fail. It appears that it tries to fall back to SSLv3, but if you >>have >> SSLv3 disabled, the whole thing just fails. >> >> My SSL Connector looks like this: >> <Connector SSLEnabled="true" URIEncoding="UTF-8" acceptCount="100" >> clientAuth="false" debug="1" disableUploadTimeout="true" >> enableLookups="false" keystoreFile="../keystore.jks" >> keystorePass="password" maxHttpHeaderSize="8192" >>keyAlias="selfsigned" >> port="8443" protocol="org.apache.coyote.http11.Http11Protocol" >> scheme="https" secure="true" >> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"> >> >> >> https://localhost.:8443 in Chrome 38 returns >> ERR_SSL_VERSION_OR_CIPHER_MISMATCH. >> >> The output from javax.net.debug=all contains this: >> http-bio-8443-exec-5, handling exception: >> javax.net.ssl.SSLProtocolException: Illegal server name, >> type=host_name(0), name=localhost., value=6c:6f:63:61:6c:68:6f:73:74:2e >> >> This looks like it’s being bubbled up from the SNIHostName constructor >>in >> Java 8 >> >>(https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SNIHostName.html >>), >> which explicitly forbids trailing dots in hostnames (valid hostname, >>but >> not a valid SNI hostname). I’m not using SNI, but to make sure I set >> jsse.enableSNIExtension=false. The exception is still thrown, leading me >> to believe that the SNIHostName constructor is being called whether SNI >>is >> enabled or not. >> >> >> Why not just remove the trailing dot? Well, it’s valid to be there, so >>why >> not support it. More importantly, we make use of this to get around TLS >> session caching as discussed here: >> https://developer.apple.com/library/ios/qa/qa1727/_index.html. >> >> >> This issue is not present in Tomcat 7 or using Java 7. I have a small >>PoC >> I can zip up and host somewhere if anyone wants to take a look. >> >> Does anyone know if this looks like a bug in Tomcat 8 or Java 8 and >>where >> I should submit a bug report if it does? > >Read the spec: >http://tools.ietf.org/html/rfc6066#section-3 > >[quote] > "HostName" contains the fully qualified DNS hostname of the server, > as understood by the client. The hostname is represented as a byte > string using ASCII encoding without a trailing dot. >[/quote] > >SNI is a TLS extensions and as such it requires minimum of TLS 1.0 and >cannot be transmitted via SSL 3.0. > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org >
