Netscape encountered bad data
I have read through the list about this problem. The way I understood is that, if one is using OpenSSL 0.9.2b, this would not be a problem. This was what I was hoping for when I was installing Apache-1.3.6 + php-3.0.7 + mod_ssl-2.2.8 + OpenSSL-0.9.2b in my FreeBSD 3.1-RELEASE. Unfortunately, I encountered this problem. The error_logs shows, [Thu Apr 15 10:53:31 1999] [error] mod_ssl: SSL handshake failed (client 203.172.25.191, server tabaco.cats.edu.ph:443) (OpenSSL library error follows) [Thu Apr 15 10:53:31 1999] [error] OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure What's wrong? -- riko __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: dynamic renegotiation
Ralf S. Engelschall wrote: On Wed, Apr 14, 1999, Matthias Loepfe wrote: A renegotiation only happens if: 1.) if current cipher is not contained in the new cipher list 2.) if current cert chain length is longer than the verify depth 3.) if verify client is required and no peer cert is available 4.) Ok, I've though about this now again and think your suggestions are ok, but technically read the following for mod_ssl: A renegotiation _has_ to be performed... o If the currently active cipher is not contained in the reconfigured/new cipher suite. o If the currently active verify type is less (strong) than the reconfigured/new verify type (order is: none optional_no_ca optional require) o If the currently active verify depth is greater than the reconfigured/new verify depth. Additionally the following optimization is possible: When the currently active verify type is "none" but a client certificate is already known/present, it's enough to manually force a client verification but skip the renegotation handshake itself. Thats exactly what I meant. But As soon a you enable your EXPERIMENTAL code (ServerCert, CACerts) there will come aditional rules. Is this optimized approach still secure? This morning a had a longer discussion with the security responsibles of a large bank. At the end we concluded that it should be ok to do it this way. The only thing which arose was that you cannot guarantee a client that there will be always the best possible cipher used. That means if you have two location with different cipher-lists configured, it is possible that the client chooses tho different cipers to communicate with one of thge locations depending if before there was a communication with the other one: Example: Location /a SSLCipherSuite DES-CBC3-SHA:RC4-SHA /Location Location /b SSLCipherSuite RC4-SHA /Location If the client first connect to '/b' and the to '/a' it will use RC4-SHA other wise it will use DES-CBC3-SHA But we also agreed that this is not really a reason not to optimize the renegotiation. regards Matthias --- Matthias Loepfe, AdNovum Informatik AG, Roentgenstr. 22, CH-8005 Zurich Email: [EMAIL PROTECTED] Voice: +41 1 272 6111 Fax: +41 1 272 6312 __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
NameVirtualHost and Multiple SSL Keys
I have an Apache 1.3.6 webserver with mod_ssl 2.2.8 and have been using this Apache/mod_ssl combination for some time now. Recently I have set it up with the NameVirtualHost option to allow different personalities for its different HostNames. What I am trying to do is allow each VirtualHost to have its own SSL key for its respective HostName. I have duplicated the appropriate VirtualHost section and all works well except the serving of the separate keys. Although each VirtualHost section is told to serve a different server.key and server.crt file it seems to serve the same key out of both VirtualHosts. It serves the key/crt from the first instance of the SSL VirtualHost (or possibly the key/csr based on the actual hostname, not the appropriate CNAME). I think it might be related to the caching the webserver does with the authority information but these sections aren't allowed in the VirtualHost area. Is it possible to accomplish this without setting up the different servers on different ports (ie. different config files)? I like the NameVirtualHost option and what it buys me in the form of administration simplicity. It doesn't look good when the browser complains about the hostname mismatch. I would appreciate any information. Thanks -- Ken Filipps [EMAIL PROTECTED] "What was the best thing before sliced bread?" -- __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: dynamic renegotiation
On Fri, Apr 16, 1999, Matthias Loepfe wrote: [...] A renegotiation _has_ to be performed... o If the currently active cipher is not contained in the reconfigured/new cipher suite. o If the currently active verify type is less (strong) than the reconfigured/new verify type (order is: none optional_no_ca optional require) o If the currently active verify depth is greater than the reconfigured/new verify depth. Additionally the following optimization is possible: When the currently active verify type is "none" but a client certificate is already known/present, it's enough to manually force a client verification but skip the renegotation handshake itself. Thats exactly what I meant. But As soon a you enable your EXPERIMENTAL code (ServerCert, CACerts) there will come aditional rules. Additional rules? You mean when people use it they will find out more optimization possibilities? Ok, as long as they're not causing security risks, that's no problem. BTW, I've now implemented it this way: Unless one uses "SSLOptions +OptRenegotiate" the paranoid approach is used where a renegotiation is forced whenever something is changed on the parameters. With "+OptRenegotiate" it's done the optimized way described above. I've just still one problem: The "manually force a client verification" seems to be not supported by OpenSSL and is actually not possible when the client already resumed the connection. And I'm still not sure what we can assume in this situation (i.e. whether the present cert is really already verified). So the problem is this: 1. The client connects with a certificate and sends the HTTP request. 2. mod_ssl determines that client auth is needed on a per-dir basis and foces a renegotiation. 3. The client now upgrades the connection by presenting the client certificate. 4. mod_ssl accepts it and sends the response. 5. The client creates a new forthcoming or even parallel connection by resuming the last session, i.e. it immediately connects with the _upgraded_ state, i.e. already presents the certificate in the initial handshake. 6. The clients HTTP request again hits the per-dir client auth requirements. 7. What can mod_ssl now assume when it finds out that client auth is requested and a peer certficate is present? Because under 7.) mod_ssl usually _CANNOT_ any longer verify the certificate chain because it's no longer present (OpenSSL stores only the peer certificate but not the chain). Can mod_ssl now assume that it already has verified it once in a previous session? I think mod_ssl can assume this as long as it can make sure the connection is a resumed one. When it's a not-resumed one (i.e. client connected with a certificate although mod_ssl hasn't requested it) I think mod_ssl has to still force a renegotiation, because the present certificate then wasn't verified. Location /a SSLCipherSuite DES-CBC3-SHA:RC4-SHA /Location SSLCipherSuite RC4-SHA /Location If the client first connect to '/b' and the to '/a' it will use RC4-SHA other wise it will use DES-CBC3-SHA But we also agreed that this is not really a reason not to optimize the renegotiation. Yes, I've thought about this, too. And that actually was the initial reason I created the OptRenegotiate option. To allow the user to choose himself whether this optimization is wanted by him. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: NameVirtualHost and Multiple SSL Keys
On Fri, Apr 16, 1999, Ken Filipps wrote: I have an Apache 1.3.6 webserver with mod_ssl 2.2.8 and have been using this Apache/mod_ssl combination for some time now. Recently I have set it up with the NameVirtualHost option to allow different personalities for its different HostNames. What I am trying to do is allow each VirtualHost to have its own SSL key for its respective HostName. I have duplicated the appropriate VirtualHost section and all works well except the serving of the separate keys. Although each VirtualHost section is told to serve a different server.key and server.crt file it seems to serve the same key out of both VirtualHosts. It serves the key/crt from the first instance of the SSL VirtualHost (or possibly the key/csr based on the actual hostname, not the appropriate CNAME). I think it might be related to the caching the webserver does with the authority information but these sections aren't allowed in the VirtualHost area. Is it possible to accomplish this without setting up the different servers on different ports (ie. different config files)? I like the NameVirtualHost option and what it buys me in the form of administration simplicity. It doesn't look good when the browser complains about the hostname mismatch. FAQ: http://www.engelschall.com/sw/mod_ssl/docs/2.2/ssl_faq.html#ToC30 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Problems with IE 4.0 German Version
Hi, We have always the same problem with the IE 4.0 SP1 German (4.72.3110.8). We use Apache 1.3.6 with mod_ssl 2.2.8 and PHP 3.0.7 on Solaris 2.5.1 (The same problem is also with the Stronghold 2.4.2 webserver). When I connect to the secure webserver IE 4.0 say: "Die übertragene Datei ist nicht verfügbar. Dies könnte möglicherweise durch die Sicherheits- oder Spracheinstellungen verursacht worden sein, oder die angeforderte Datei konnte nicht vom Server geladen werden." With the IE 4.0 english same Version and IE 4.0 SP1a german work fine.Had anyone a solution for our problem ? Thank you. Stephan Toggweiler __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Core dump
All of a sudden, any new compile of Apache with mod_ssl coredumps on me. I
was able to compile/run 2.2.7 fine shortly after it came out, but now I
can no longer get 2.2.7 or 2.2.8 to work anymore. Non-SSL Apaches compile
and run fine. I can't think of any libraries that I've upgraded since
then.
Linux 2.0.36 (Red Hat 5.2 on Intel)
Apache 1.3.6
Mod_SSL 2.2.8 or 2.2.7 (2.2.7 used to work fine, but doesn't anymore)
OpenSSL 0.9.2b (with rsaref patch)
Mod_Perl 1.19
PHP 1.0.7
Apache core's shortly after I input the CA passphrase. Strace output
follows:
write(2, "Enter pass phrase:", 18Enter pass phrase:) = 18
fstat(4, {st_mode=S_ISGID|0400, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x295630
00
ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0
read(4, 0x29563000, 4096) = ? ERESTARTSYS (To be restarted)
--- SIGWINCH (Window changed) ---
read(4, "password_deleted_for_security_reasons\n", 4096) = 15
write(2, "\n", 1
) = 1
ioctl(4, TCSETA, {B38400 opost isig icanon echo ...}) = 0
sigaction(SIGHUP, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGINT, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGQUIT, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGILL, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGTRAP, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGABRT, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGBUS, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGFPE, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGSEGV, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGPIPE, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGALRM, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGTERM, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGSTKFLT, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGCHLD, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGCONT, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGTSTP, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGTTIN, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGTTOU, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGURG, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGXCPU, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGXFSZ, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGVTALRM, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGPROF, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGWINCH, {SIG_DFL}, {SIG_DFL}) = 0
sigaction(SIGIO, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGPWR, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
sigaction(SIGUNUSED, {SIG_DFL}, {0x8149924, [], 0x4}) = 0
close(4)= 0
munmap(0x29563000, 4096)= 0
dup2(10, 2) = 2
getpid()= 28961
getpid()= 28961
lseek(3, 0, SEEK_SET) = 0
getpid()= 28961
read(3, "-BEGIN RSA PRIVATE KEY-\n"..., 1024) = 963
getpid()= 28961
getpid()= 28961
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
Help!
-Aaron Turner
__
Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Verisign GlobalID
Hi, I'm trying to install a GlobalID into the c2 Stronghold server which is pretty similar to modssl (I have to use Stronghold because it's for a commercial server in the US). I'm having a lot of trouble and found some messages about GlobalID's in the sw-mod-ssl archives so I thought I'd ask for advice here. The problem is that the GSID is delivered as two separate certificates that need to be chained. There is the GSID itself and an intermediate cert that signs it. Simply dropping the intermediate cert into the directory pointed to by SSLCACertificatesPath doesn't seem to help. The browser acts like it's just received a the GSID itself which it treats as a valid cert signed by an unknown issuer, so I don't get the 128 bit step-up. Connecting with ssleay's s_client shows a 1-deep cert chain: the GSID and the intermediate cert. Only one certificate seems to be displayed. Connecting to another machine presenting a GSID from Netscape Proxy Server gives a 2-deep chain: the GSID, the intermediate cert, and the Verisign Class 3 Public Primary CA. Again, it only shows one PEM cert, but it's about twice as long as the one that I get from Stronghold. Anyway I'm wondering, has anyone here gotten a real Verisign GlobalID (not a non-chained selfsigned one with a patched cert7.db file) to work with modssl? What did you do to install the intermediate cert? Is there some tool that combines the certs in a chain into one PEM file? Has the GSID been observed to work (i.e. to give 128 bit crypto and not cause disconnects) in both Netscape and MSIE browsers? Thanks very much for any advice. Paul __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Netscape encountered bad data
I was able to make it work already (talk about answering your own questions). What I did was to recompile OpenSSL-0.9.2b. I made a mistake in recompiling it. This was what I did at first, # cd openssl-0.9.2b # ./configure # make Obviously this was not the way to do it according to the installation instructions. It should have been, # cd openssl-0.9.2b # make -f Makefile.ssl links # perl ./Configure gcc # make All is well now =) On Fri, 16 Apr 1999, CATS Administrator wrote: I have read through the list about this problem. The way I understood is that, if one is using OpenSSL 0.9.2b, this would not be a problem. This was what I was hoping for when I was installing Apache-1.3.6 + php-3.0.7 + mod_ssl-2.2.8 + OpenSSL-0.9.2b in my FreeBSD 3.1-RELEASE. Unfortunately, I encountered this problem. The error_logs shows, [Thu Apr 15 10:53:31 1999] [error] mod_ssl: SSL handshake failed (client 203.172.25.191, server tabaco.cats.edu.ph:443) (OpenSSL library error follows) [Thu Apr 15 10:53:31 1999] [error] OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure __ Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
