Re: svn commit: r122551 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/modules/proxy/mod_proxy.c
Jim Jagielski wrote: Mladen Turk wrote: I plan on adding additional info to it, to better define how to use it. The docs are kinda skimpy right now. Cool! I also work on the howto or example section for using mod_proxy from simple setup to the work in the clustered environment. I will also have a table with detailed descriptions for each proxy and balancer property. Only not sure where to put it :). Mladen.
Re: SSL + name based virtual hosting
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Hi, Using another spec, connection upgrade TLS, it works perfectly, but that spec is only supported by some printer drivers. No http client supports TLS upgrade that I'm aware of. where're the differences between SSL and TLS handshake ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: SSL + name based virtual hosting
* Dale Ghent [EMAIL PROTECTED] wrote: Hi, snip With SSL, this HTTP request is already encrypted. The server will need to have a way to figure out what SSL key to use to decrypt that HTTP request, but can't do it unless it knows what host/site address the request is for so it can use the correct key... so, this is why SSL hmm, is it somehow possible to work with multiple cert on the same socket ? does the SSL handshake leave any chance that probably more then one cert can be tried, until someone matches ? if this would be possible, we could give each vhost an own cert (instead of wildcard certs) and let the httpd+client try out, which cert matches - based on the matched cert we know which vhost is requested ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: SSL + name based virtual hosting
At 11:23 AM 12/17/2004, Enrico Weigelt wrote: hmm, is it somehow possible to work with multiple cert on the same socket ? does the SSL handshake leave any chance that probably more then one cert can be tried, until someone matches ? No. That isn't in the spec, and would be horribly inefficient. where're the differences between SSL and TLS handshake ? Explicit SSL (https: e.g. port 443) demands the client and server handshake an ssl tunnel, totally independent of the http protocol. It's a bunch of ssl handshake bytes, until the connection has been established and the http conversation can begin. This is exactly the same handshake you would see on an ldaps: port 636 connection, or a pop3s connection over port 995. The protocol underneath doesn't matter. Implicit, or StartSSL (StartTLS) protocol means that a protocol specific request to begin an SSL/TLS handshake. This is how you can have an ldap: port 389 connection turn into an encrypted conversation. It isn't supported by Netscape/Sun/Mozilla LDAP, but is supported by modern OpenLDAP tools. Just as StartTLS for LDAP isn't widely supported yet, neither is the Connection-upgrade header. Our httpd-2.1 server has this support, but no 'browers' that I know of support it. http://httpd.apache.org/docs-2.1/mod/mod_ssl.html#sslengine There are remote printer devices which do support this feature, so there is even talk of introducing the feature into httpd 2.0. In any case, the browser community has an issue, because how do you assure a user that a connection to http://foo.com/buy.html is secure(d) using connection-upgrade? http://www.ietf.org/rfc/rfc2817.txt spells out methods that the server can -insist- that an upgraded connection is used, and the client can instigate an upgraded connection as well even if the server doesn't require it. But under no conditions is https:// valid for an upgraded connection. The connection never left port 80. The scheme http:// describes a connection to (default) port 80 started as clear text, while the https:// scheme describes an explicit SSL connection to (default) port 443. Upgrade is an addendum to the http:// scheme. If the server demanded an upgrade, the GUI issue is simple, just show the lock icon. The http:// is still not very reassuring, but everyone is used to looking at the little locked icon. But how does a user demand a secured connection when useful but not required, and not choose one when it's useless? Is there some domain list stored in the user's browser to insist on which sites will be forced to upgrade? Do they get a clicky button to toggle the upgrade? These aren't trivial questions, which is why this four year old mechanism has been ignored for so long. Long and short of it, unless you use a single wildcard certificate matching all of your domains, you can't host them on a single listening address/port with https. Bill
mod_ssl: ./configure throwing warnings
Hi all, While building the trunk of httpd (as an RPM), I am getting the following warning while configure runs: checking whether to enable mod_ssl... checking dependencies checking for SSL/TLS toolkit base... none checking for OpenSSL version... checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... no configure: WARNING: openssl/ssl.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: openssl/ssl.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for openssl/ssl.h... no not encouraging WARNING: OpenSSL version may contain security vulnerabilities! Ensure the latest security patches have been applied! checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes The system is a Yellowdog Linux v3.0 (LinuxPPC) system, with openssl at openssl-0.9.7a-33.4a. Any ideas? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
SSL/VHost logging to Syslog
Is there a way to have certain log data (particularly a new session) piped to syslog natively in apache? Are there third party modules which implement this functionality? I would like to avoid re-inventing the wheel if I dont have to. -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. pgpkQFO6kL9XP.pgp Description: PGP signature
SSL re-inits and re-negotiations
I notice in my SSL Error log (with Debug on) that upon startup, initialization seems to happen twice. [Fri Dec 17 13:57:53 2004] [info] Loading certificate private key of SSL-aware server [Fri Dec 17 13:57:53 2004] [info] Init: Requesting pass phrase via builtin terminal dialog [Fri Dec 17 13:58:02 2004] [debug] ssl_engine_pphrase.c(474): encrypted RSA private key - pass phrase requested [Fri Dec 17 13:58:03 2004] [info] Configuring server for SSL protocol [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(404): Creating new SSL context (protocols: SSLv3, TLSv1) [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(521): Configuring client authentication [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(536): Configuring certificateRequest message [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(1080): CA certificate: ... [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(587): Configuring permitted SSL ciphers [RSA:... [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(612): Configuring certificate revocation facility [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(715): Configuring RSA server certificate [Fri Dec 17 13:58:03 2004] [debug] ssl_engine_init.c(754): Configuring RSA server private key [Fri Dec 17 13:58:03 2004] [info] Loading certificate private key of SSL-aware server [Fri Dec 17 13:58:03 2004] [info] host.domain.name reusing existing RSA private key on restart [Fri Dec 17 13:58:05 2004] [info] Configuring server for SSL protocol [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(404): Creating new SSL context (protocols: SSLv3, TLSv1) [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(521): Configuring client authentication [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(536): Configuring certificateRequest message [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(1080): CA certificate: /... [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(587): Configuring permitted SSL ciphers [RSA:... [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(612): Configuring certificate revocation facility [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(715): Configuring RSA server certificate [Fri Dec 17 13:58:05 2004] [debug] ssl_engine_init.c(754): Configuring RSA server private key Questions: Why is this? I noticed a similar situation for a single request. I get two complete handshakes? I initially thought it was because both my base server and virtual host needed an SSL context. However, I dropped use of my vhosts and I still get the same behavior. I am just curious. No problems. I have seen the for loop in ssl_engine_init.c [ssl_init_Module()] that seems to traverse a linked list of server_rec next-pointers. If all I have is a base server config why the duplication of initialization and handshakes? regards, tt 317-510-5987
RELEASE directory change
Greetings All, Doing a build of httpd-2.1-dev for NetWare on Win and find the Release directories are now /release.o ... is this intended behaviour? Norm
Re: RELEASE directory change
Yes, a new module directory called debug was added as a subdirectory of modules. This conflicted with the debug output directory that was being created during the build process. The result was that everytime you did a gmake -f NWGNUMakefile clean it wiped out the source code found in the new modules/debug directory. So both the build debug and release directories were renamed to debug.o and release.o. Brad [EMAIL PROTECTED] Friday, December 17, 2004 2:58 PM Greetings All, Doing a build of httpd-2.1-dev for NetWare on Win and find the Release directories are now /release.o ... is this intended behaviour? Norm
Re: RELEASE directory change
Brad Nicholes wrote: Yes, a new module directory called debug was added as a subdirectory of modules. This conflicted with the debug output directory that was being created during the build process. The result was that everytime you did a gmake -f NWGNUMakefile clean it wiped out the source code found in the new modules/debug directory. So both the build debug and release directories were renamed to debug.o and release.o. Brad [EMAIL PROTECTED] Friday, December 17, 2004 2:58 PM Greetings All, Doing a build of httpd-2.1-dev for NetWare on Win and find the Release directories are now /release.o ... is this intended behaviour? Norm . Good morning, Thanks for the feedback... all goes well then! :-) Norm
Re: SSL + name based virtual hosting
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Using a wildcard cert, this simply works, as long as the common name pattern matches all server names. are wildcard certs generally accepted by the current cohort of browsers? -- joe
Re: RELEASE directory change
At 04:15 PM 12/17/2004, you wrote: Yes, a new module directory called debug was added as a subdirectory of modules. This conflicted with the debug output directory that was being created during the build process. That's a pretty big stick, and Win32 suffers similar issues. Can't we simply rename that module tree to 'debugging'? Moving directories no long breaks history. Bill
Re: SSL + name based virtual hosting
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote: snip http://www.ietf.org/rfc/rfc2817.txt spells out methods that the server can -insist- that an upgraded connection is used, and the client can instigate an upgraded connection as well even if the server doesn't require it. But under no conditions is https:// valid for an upgraded connection. The connection never left port 80. The scheme http:// describes a connection to (default) port 80 started as clear text, while the https:// scheme describes an explicit SSL connection to (default) port 443. Upgrade is an addendum to the http:// scheme. What fools are sitting there in the IETF ?! Couldn't they just define a new protocol (probably running on its own port) which allows specifying additional headers *before* SSL handshake starts or another SSL version, which allows passing additional info from client-server before certs are exchanged/checked ? Life could be so easy this way - probably too easy ... Well, that were the same folks who invented IPSEC, which is not NAT'able. It seems its the we have enough IP addresses-sickness ... ... its time to completely redesign HTTP ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
