[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Mark Thomas --- This is implemented in Tomcat 9 for NIO, NIO2 and APR/native. Note that the configuration refactoring isn't complete yet but the building blocks are all in place. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #15 from quartz --- nio: ok. Sorry. As for TLS parsing, there can be a whole lot of stuff well beyond 100 bytes in client hello, namely yet unknown extensions. TLS records proto msg length is up to 2^14-1 bytes. Not an issue I guess. Also, I just read that with a DHE handshake the SNI could come later and encrypted. https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-4 So, if they have it their way, it won't be enough to look ahead the clienthello in 1.3. But I won't bet on that delayed encrypted sni; it is paranoiac protection because the DNS lookup just before is pretty much revealing the same info. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #12 from Mark Thomas --- Keeping the config at the connector level is probably the way to go. There are weird and wonderful configuration possibilities like one Connector on one interface with one set of certs for internal users and another connector on another interface with another set of certs for external users that share the same hosts. I think we should keep the TLS cert <-> host name mapping completely independent from the Host <-> host name mapping. Most folks will have them aligned but some will want to do soemthign different. Using ... should allow some config copy/paste for those that want to. SNI is mandatory for HTTP/2 so this has just jumped to the top of my TODO list. I'm thinking along the lines of the the configuration style in comment#7. I've also been thinking about trying to merge the JSSE and OpenSSL configuration attributes. I'm not sure if it will work but the idea is to deprecate setting these on the connector and add a defaultTLSAlias="" element to the Connector that references the cert to use if nothing else matches. If the existing configuration attributes are used on the Connector then they are mapped to a TLSAlias element with a pre-defined name (probably default or something similar), along with a deprecated config warning. I don't know how feasible this merging plan is but if it works, in addition to simpler config, it should allow further simplification of the Http11*Protocol implementations. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #11 from Christopher Schultz --- (In reply to Unlogic from comment #10) > Well this is a bit tricky because there is two sides to this coin. > > In some cases you have a wildcard certificates or subject alternative name > certificates the cover lots of domains. In those cases the current connector > based approach works fine fine. We have to continue to support the current connector configuration, anyway. I figured that whatever configuration the had would be the default for all of the hosts. In that case, you'd probably want to put the wildcard cert, etc. on the and do nothing special for each host. > A trade off between the two solutions could be to define the keystores using > a separate element in the config like when you define a connection pool. And > then make it possible for both the connectors, hosts and aliases to refer > back to the defined keystores depending on the use case. > > Here's an example: > > name="firstKeystore" > truststoreFile="..." (and other truststore attributes) > keystoreFile="..." (and other keystore attributes) > [other allowed configuration attributes]> This is pretty much what my proposal was, except that they would be explicitly-referenced from and/or instead of being nested within. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #10 from Unlogic --- Well this is a bit tricky because there is two sides to this coin. In some cases you have a wildcard certificates or subject alternative name certificates the cover lots of domains. In those cases the current connector based approach works fine fine. But if you turn things around and have lets say 50 domains all with their own host and certificate and maybe even a few aliases for some hosts that in turn also require separate certificates. In that case the host based approach would make things simpler since you can put everything inside the hosts element. A trade off between the two solutions could be to define the keystores using a separate element in the config like when you define a connection pool. And then make it possible for both the connectors, hosts and aliases to refer back to the defined keystores depending on the use case. Here's an example: (a generic https connector not bound to any particular keystore that instead looks up the keystore based on the host/alias) (a https connector bound to the specified keystore like current tomcat versions) (a host not bound to any particular keystore) foo.com boo.com moo.com I hope that my example makes sense. It would make the keystore/certificate configuration a bit more flexible and support "both sides of the coin". -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #9 from Christopher Schultz --- I'm starting to re-think the configuration because it's starting to look a lot like the configuration. Would it make more sense to put the TLS configuration on the element instead? This would be more in line with Apache httpd, for instance. The connector would have to reach-into the configuration to pick-up all the configuration. I'm not sure if this is a good idea (or even possible), but from a human configuration perspective, I think that using the as the container for TLS configuration makes more sense than having it on the . -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #8 from Christopher Schultz --- That sounds reasonable to me. Since the configuration for each hostname would need to be maintained separately, being able to tie several hostnames together would be beneficial. On the other hand, if regular expressions are used for hostnames, the complxity can be handled there instead of in a slightly larger look-up table with aliases, etc. Honestly, even though I mentioned it as a possibility, I think that the use of regular expressions for hostname matching is probably more overhead than anyone wants to perform for every TLS request that comes through the door. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #7 from Unlogic --- I think that sounds like a very good approach which would be easy to add to existing server configurations. Since a single certificate can contain multiple subject alternative names (http://en.wikipedia.org/wiki/SubjectAltName) which may be very different from each other I would propose to use an approach similar to the way aliases are added to hosts. somehost.com anotherhost.com averydifferenthost.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #6 from Christopher Schultz --- Proposed configuration vocabulary, which is backward-compatible with existing configurations: The TLS configuration attributes on the will become the default TLS configuration for a request for a hostname that does not match any of the elements' hostname fields. Any request that exactly matches a hostname (or, perhaps we can do prefixing, globbing and/or regular expressions if people want to do that kind of thing) will instead use the TLS configuration of its matching element. There are some configuration elements that are appropriate to allow a element to override from the default. Proposed are all but those that appear in the following section. There are some attributes that should probably not be overridable in the elements, due their effect on all connections. Proposed attributes: SSLProtocol Care must be taken to ensure that subsequent handshakes -- for example, for the purposes of client re-negotiation or cipher-suite-switching -- do not allow a single client to switch from one hostname to another to, for instance, avoid some part of the authentication scheme or take advantage of a faulty configuration in host alias in order to "upgrade" to a different host with more stringent requirements. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #5 from Unlogic --- This will surely be a killer function if it makes to Tomcat 9. As the use of Windows XP is fading out the demand for SNI support is increasing by the day. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 Unlogic changed: What|Removed |Added CC||unlo...@unlogic.se -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 Mark Thomas changed: What|Removed |Added Component|Connectors |Connectors Version|trunk |unspecified Product|Tomcat 8|Tomcat 9 Target Milestone||- --- Comment #4 from Mark Thomas --- Move to Tomcat 9 now it exists. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 Ralf Hauser changed: What|Removed |Added CC||hau...@acm.org --- Comment #3 from Ralf Hauser --- see also http://stackoverflow.com/questions/20190464/howto-setup-tomcat-serving-two-ssl-certificates-using-sni and https://en.wikipedia.org/wiki/Server_Name_Indication -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 --- Comment #2 from Christopher Schultz --- This may be an opportunity to fix the inability to respond to HTTP requests on HTTPS endpoints. We get complaints every once in a while that if you "telnet host 443" against Tomcat, you get a hung connection while with httpd, you get an "400 Bad Request" response that actually says "you are making an HTTP connection to an HTTPS server". Completely changing the infrastructure and handling of secure sockets isn't justified merely to scratch this itch, but supporting SNI is a much bigger motivating force. Scratching this itch simultaneously would be great. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 Mark Thomas changed: What|Removed |Added Component|Common |Connectors Version|unspecified |trunk Product|Tomcat Connectors |Tomcat 8 Target Milestone|--- | --- Comment #1 from Mark Thomas --- Correct the component - this has nothing to do with the Connectors component which is the web server end of the AJP implementation. Tomcat 8 has to run on a minimum of Java 7 so this is something on the roadmap for Tomcat 9. Leave this in Tomact 8 until work starts on Tomcat 9 and the product exists in Bugzilla. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 Chuck Caldarale changed: What|Removed |Added Severity|normal |enhancement -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57108] Implement multiple sslcontext SNI (server name indication) dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=57108 quartz changed: What|Removed |Added CC||quartz...@yahoo.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
