Re: mod_ssl, SNI and dynamic virtual hosts
Adam Hasselbalch Hansen wrote: Thomas, Peter wrote: -Original Message- From: Adam Hasselbalch Hansen [mailto:a...@one.com] Sent: Tuesday, May 25, 2010 7:06 AM To: dev@httpd.apache.org Subject: Re: mod_ssl, SNI and dynamic virtual hosts So what I'm attempting to get feedback on is whether or not it will be possible or even feasible to move certificate loading (as in the actual reading of certificate files) from startup time to request time, and if so, what caveats if any this may lead to. Loading processing server certificates, keys, trust chains, and CRLs Request time doesn't make sense to me, unless it's implemented as a one-time cost for the first use of a dynamic virtual host. Are these virtual hosts truly dynamic? It seems that there would have to be some a priori knowledge of the possible servers you might be hosting. Are you Not in a consistent way. Dynamic hosts can (and will) be added or removed from under Apache's nose without restarting it. in fact proposing some mechanism whereby you provide a path generator as in certs/%s/server.crt where Apache will look for the certificates [and other files] defining the PKI environment for each dynamic virtual host, and that further these files might not have been present on the system at httpd's startup? That is exactly what I am proposing. Any further comments? It seemed like you had more to say :) -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com
Re: mod_ssl, SNI and dynamic virtual hosts
Thomas, Peter wrote: -Original Message- From: Adam Hasselbalch Hansen [mailto:a...@one.com] Sent: Tuesday, May 25, 2010 7:06 AM To: dev@httpd.apache.org Subject: Re: mod_ssl, SNI and dynamic virtual hosts So what I'm attempting to get feedback on is whether or not it will be possible or even feasible to move certificate loading (as in the actual reading of certificate files) from startup time to request time, and if so, what caveats if any this may lead to. Loading processing server certificates, keys, trust chains, and CRLs Request time doesn't make sense to me, unless it's implemented as a one-time cost for the first use of a dynamic virtual host. Are these virtual hosts truly dynamic? It seems that there would have to be some a priori knowledge of the possible servers you might be hosting. Are you Not in a consistent way. Dynamic hosts can (and will) be added or removed from under Apache's nose without restarting it. in fact proposing some mechanism whereby you provide a path generator as in certs/%s/server.crt where Apache will look for the certificates [and other files] defining the PKI environment for each dynamic virtual host, and that further these files might not have been present on the system at httpd's startup? That is exactly what I am proposing. Thank you, -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com
Re: mod_ssl, SNI and dynamic virtual hosts
Adam Hasselbalch Hansen wrote: We have a setup that uses an in-house module which works not entirely unlike mod_vhost_alias, in that it has a single virtual host configured, and then determines stuff like domain name, docroot, etc, from the request. We'd love to be able to use SSL in this setup, but as far as I can see, the only way to do this would be to change (i.e. hack) mod_ssl to do the certificate loading sometime around request-time, since the apache server and SSL have no clue what virtual hosts they will be serving at startup. How would such a hack, if at all possible, affect stuff like certificate caching and other things? I'd love any feedback! Anyone? -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com
Re: mod_ssl, SNI and dynamic virtual hosts
Ivan Ristic wrote: You are assuming that the domain name will be in the SSL handshake. While it will be, in many cases, a very large number of browsers won't send it. In particular, Internet Explorer running on Windows XP does not support SNI. For more information, have a look at: http://en.wikipedia.org/wiki/Server_Name_Indication Once SNI becomes widely adopted (i.e. Windows XP dies), then, yes, you may need to resort to resolving certificates at run-time to support your setup . Yes, I know about SNI, and while your points are all valid, they have little to do with my question. :) For the sake of the argument, assume that all http clients in the world sends SNI every time. The problem then is configuration and certificate loading. At startup, with dynamic virtual hosts (a la mod_vhost_alias), Apache can not know which virtual hosts it is going to serve, and thus mos_ssl has no idea about which certificates to load. So what I'm attempting to get feedback on is whether or not it will be possible or even feasible to move certificate loading (as in the actual reading of certificate files) from startup time to request time, and if so, what caveats if any this may lead to. -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com
mod_ssl, SNI and dynamic virtual hosts
We have a setup that uses an in-house module which works not entirely unlike mod_vhost_alias, in that it has a single virtual host configured, and then determines stuff like domain name, docroot, etc, from the request. We'd love to be able to use SSL in this setup, but as far as I can see, the only way to do this would be to change (i.e. hack) mod_ssl to do the certificate loading sometime around request-time, since the apache server and SSL have no clue what virtual hosts they will be serving at startup. How would such a hack, if at all possible, affect stuff like certificate caching and other things? I'd love any feedback! -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com
Re: [PATCH 43415] Logging remote port.
Plüm wrote: 1. Please provide a patch against trunk. mod_config_logger.c hasn't changed in trunk, so the patch will work fine. 2. Please also add a patch for the documentation. Done. 3. I am not too happy with using %R, but to be honest I have no better proposal :-). Maybe other have. Well, then... ;) 4. Instead of using + return apr_psprintf(r-pool, %u, r-connection-remote_addr-port); I would prefer + return pfmt(r-pool, (int) (r-connection-remote_addr-port)); like used for log_status. Well, in log_server_port, apr_psprintf is used, so that's what I used. But I really don't care one way or the other. Is there a particular reason for using one or the other? 5. Thanks for your patch :-). Welcome :) /Adam
Re: [PATCH 43415] Logging remote port.
Nick Kew wrote: Looks more like legislation for ISPs than folks with a webserver. ISPs and hosting companies alike. I'd be sceptical about that applying to non-sessions such as HTTP requests. I think that semantics are lost on these people. Part 4: [Requirements don't apply if they're not technically possible to meet] So if Apache doesn't support this, you're exempt, yesno? :-) No, that's the beauty of it. If it is not technically possible to log stuff, then you just have to log every 500 packets instead. Go figure /Adam
[PATCH 43415] Logging remote port.
I have created a patch for httpd 2.2.6, giving the additional LogFormat directive %R, which logs the port of the host making the request. This is due to new legislation in Denmark, requiring ISPs and hosting companies to log the originating port of all traffic. Any feedback is appreciated :) Thanks, Adam
Re: [PATCH 43415] Logging remote port.
Nick Kew wrote: On Tue, 18 Sep 2007 12:25:18 +0200 Adam Hasselbalch Hansen [EMAIL PROTECTED] wrote: I have created a patch for httpd 2.2.6, giving the additional LogFormat directive %R, which logs the port of the host making the request. This is due to new legislation in Denmark, requiring ISPs and hosting companies to log the originating port of all traffic. Is there a reference for that legislation, and whatever debate there was surrounding it? As in, what do they expect to gain from it? Debate? It's the Justice Department that's had a brainfart, that's what's happened. Apparently it's meant to ease criminal investigations involving electronic communication (read: terror investigations). But it's totally meaningless, since public terminals (like in an Internet Cafe) are exempt from the law. You can read the entire thing in Danish here: http://www.folketinget.dk/samling/20061/Lovforslag/L63/Bilag/7/351262.PDF The relevant part is Section 5, which says (losely translated): § 5. A provider of electronic communication nets or services for end users must register the following information about an internet session's initiating and terminating package: 1. Originating Internet Protocol address 2. Recipient Internet Protocol address 3. Transport protocol 4. Originating port number 5. Recipient port number 6. Time of start and end of communication. Looks harmless, and evidently adds value for you. Well, value, schmalue. But it's the law...
