Re: Re-direct in vhost
Hello Arthur, I do not understand your question clearly. What concerns in your mind? -Kiyoshi Kiyoshi Watanabe > Hi all. > Currently I've one vhost on Port 443 and while others listen on Port 80. > I would like to test the scenario of putting *everything* on openSSL ie > listening on Port 443. > Do I assume right that all I need is a "redirect" from the Port 80 vhost to > Port 443 ? > TIA :-) > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Handshake Failure, but it looks like SSL
OnHandshake Failure, but it looks like SSL, Sam <[EMAIL PROTECTED]> said: Any help when you add -ssl3 command? -Kiyoshi Kiyoshi Watanabe > Hi all - > > I'm trying to get modssl working on a RedHat 8.0 box, which is running > modssl 2.0.40-11.7 and the apache httpd 2.0.40-11.7 (both from RPM). > > There are several NBVH on port 80, and I one VirtualHost block set to port > 443. > > When I connect, I get the following: > > $ openssl s_client -connect www.mydomain.com:443 -state -debug > CONNECTED(0003) > SSL_connect:before/connect initialization > write to 08161508 [08161550] (124 bytes => 124 (0x7C)) > - 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... . > 0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f.. > 0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d. > 0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`. > 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > 0050 - 00 00 06 00 00 03 04 00-80 02 00 80 7f 5f 29 d7 ._). > 0060 - eb 10 2c be a7 b8 42 b9-e5 86 7a b7 03 f0 e9 34 ..,...B...z4 > 0070 - 47 04 1f 94 00 c4 83 c5-0a bb c5 d7 G... > SSL_connect:SSLv2/v3 write client hello A > read from 08161508 [08166AB0] (7 bytes => 0 (0x0)) > 29523:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:s23_lib.c:226: > $ openssl s_client -connect localhost:443 -state -debug > CONNECTED(0003) > SSL_connect:before/connect initialization > write to 08160670 [08160A40] (124 bytes => 124 (0x7C)) > - 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... . > 0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f.. > 0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d. > 0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`. > 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > 0050 - 00 00 06 00 00 03 04 00-80 02 00 80 fc e7 8b 7d ...} > 0060 - 38 97 d2 c0 73 10 26 93-6e 06 61 c2 84 cc dc 6f 8...s.&.n.ao > 0070 - fd d7 69 d9 e2 92 c1 55-e4 17 a0 a4 ..iU > SSL_connect:SSLv2/v3 write client hello A > read from 08160670 [08165FA0] (7 bytes => 0 (0x0)) > 29524:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:s23_lib.c:226: > $ openssl s_client -connect localhost:443 -state -debug > CONNECTED(0003) > SSL_connect:before/connect initialization > write to 08160670 [08160A40] (124 bytes => 124 (0x7C)) > - 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... . > 0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f.. > 0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d. > 0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`. > 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > 0050 - 00 00 06 00 00 03 04 00-80 02 00 80 ca 76 f2 09 .v.. > 0060 - 0a c8 b1 ab 78 f3 c9 b3-a6 8d 34 4e 44 54 14 a5 x.4NDT.. > 0070 - 2f 18 c0 7a 96 e4 21 c5-cd 90 b2 08 /..z..!. > SSL_connect:SSLv2/v3 write client hello A > read from 08160670 [08165FA0] (7 bytes => 0 (0x0)) > 29525:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:s23_lib.c:226: > > Note how they're different (slightly) and there's no human-readable text in > there. In fact, when I connect to a working https server, I get a similar > result at the beginning. > > ($ openssl s_client -connect workingdomain.com:443 -state -debug > CONNECTED(0003) > SSL_connect:before/connect initialization > write to 08161508 [08161550] (124 bytes => 124 (0x7C)) > - 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... . > 0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f.. > 0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d. > 0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`. > 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > 0050 - 00 00 06 00 00 03 04 00-80 02 00 80 b3 30 11 07 .0.. > 0060 - d2 7f 14 32 93 4d 4c 53-3c 5d 7d 30 d8 f0 91 a8 ...2.MLS<]}0 > 0070 - 75 f6 41 b7 0c 69 58 7e-ac 6e 58 11 u.A..iX~.nX. > SSL_connect:SSLv2/v3 write client hello A > read from 08161508 [08166AB0] (7 bytes => 7 (0x7)) > - 16 03 01 00 4a 02 J. > 0007 - > ) > > > If I turn OFF the SSLEngine, I get the following: > > $ openssl s_client -connect localhost:443 -state -debug > CONNECTED(0003) > SSL_conne
Re: SSL error message
Hello, > How can i show for users some my own error page (for example, "Please insert > your ID card!")? Does the modssl have such a custom error message functionality? Also, How can the server know whether the ID card is inserted or not? The error message below only shows that the server does not recieve the client certificate that was expected. > Apache SSL error.log is: > [Thu Sep 11 12:23:37 2003] [error] OpenSSL: error:140890C7:SSL > routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate > [Hint: No CAs known to server for verification?] > [Thu Sep 11 12:23:37 2003] [error] mod_ssl: SSL handshake failed (server > erki_laptop/laev:443, client 172.100.60.2) (OpenSSL library error follows) The solution would be to have your application check whether the ID card is inserted and make sure your certficate there before you send the SSL message. -Kiyoshi Kiyoshi Watanabe __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: virtual hosting
Hi John, > If you had a wildcard certificate which worked for *.domain.com, would name > virtual hosting be possible then assuming that all your virtual hosts were > things like "secure.domain.com" and "basket.domain.com" as they are actually > all using the same wildcard certificate for the SSL handshake. I think that it is possible as long as the each domain name of your virtual hosts has the IP address associated with the inet address. I believe that the wildcard certificate and domain names are a client side issue. The browser will check the dn in URL and certificate. I do not know whether IE still accepts this certificate or not. If there are any issues in server side, I want to know them. -Kiyoshi Kiyoshi Watanabe > If anyone could answer that, it would be great and potentially save some > messing when it comes to IP addresses. > > Cheers > > JB > > -Original Message- > From: Dave Paris [mailto:[EMAIL PROTECTED] > Sent: 21 August 2003 04:59 > To: [EMAIL PROTECTED] > Cc: Ian Newlands > Subject: Re: virtual hosting > > > geeze. is it that time of the month already for this question? seems > like it was just yesterday when it was asked last .. maybe I'm just > thinking of the other 100,000 times it was asked. > > in all seriousness, this dead horse has been beaten so many times on > this list there isn't even a carcass left to hit at this point. please > go dig through the mail list archives to see why name-based virtual > hosts don't work with SSL. > > yes, that's a flippant answer. no, you're not likely to get a reply > any more serious. > > -dsp > > On Wednesday, Aug 20, 2003, at 22:09 US/Eastern, Ian Newlands wrote: > > > I am currently running about 15 virtual hosts using name based on port > > 80, and 1 virtual host using SSL. > > > > My SSL host is currently working with the following: > > > > > > > > However I want to change this to the IP based hosting for this host, > > allowing me to then add more SSL based virtual hosts on this setup, so > > I tried changing this to the following: > > > > > > > > By doing this my SSL virtual host stops working altogether. > > > > I try the following to debug it on a remote machine: > > > ># openssl s_client -connect 203.xxx.xxx.xxx:443 > >CONNECTED(0003) > >27604:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > > protocol:s23_clnt.c:475: > > > > I do the exact same thing on the local machine and it responds with a > > valid SSL response. > > > > Can anyone suggest might be wrong here? > > > > Regards, > > > > Ian Newlands > > > > _ > > Hotmail is now available on Australian mobile phones. Go to > > http://ninemsn.com.au/mobilecentral/signup.asp > > > > __ > > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > > User Support Mailing List [EMAIL PROTECTED] > > Automated List Manager[EMAIL PROTECTED] > > > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] > > This email has been scanned for all viruses by the MessageLabs SkyScan > service. > > > ** > This email and any files transmitted with it are confidential, and may be subject to > legal privilege, and are intended solely for the use of the individual or entity to > whom they are addressed. > If you have received this email in error or think you may have done so, you may not > peruse, use, disseminate, distribute or copy this message. Please notify the sender > immediately and delete the original e-mail from your system. > > Computer viruses can be transmitted by e-mail. Recipients should check this e-mail > for the presence of viruses. The Capita Group and its subsidiaries accept no > liability for any damage caused by any virus transmitted by this e-mail. > *** > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: virtual hosting
Hello, > I am currently running about 15 virtual hosts using name based on port 80, > and 1 virtual host using SSL. I assume that you have only one virtual host for SSL in your conf. > My SSL host is currently working with the following: > > > > However I want to change this to the IP based hosting for this host, > I tried changing this to the following: > > > > By doing this my SSL virtual host stops working altogether. > > I try the following to debug it on a remote machine: > > # openssl s_client -connect 203.xxx.xxx.xxx:443 > CONNECTED(0003) > 27604:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:475: I see simlilar problems several times. From my little experience, this happends when you access the virtual host where the sslengine is not on. This is caused by probably: 1) You do not specify the SSL engine on in the directive. (Probably not because you just changed from _default_:443) 2) Your virtual host is not working (happends when you try to have multiple ssl hosts). But even happends when you set a differnt IP from the one in your inet addr (even you have a one virtual host). 3) You have several ethernet HWs working and for a example use the eth0 for openssl command and eth1 for ssl.conf. > Can anyone suggest might be wrong here? I can only tell that xxx.xxx.xxx parts of your two IP addresses are probably not set correctly. If you could tell exact info on the conf and ifconfig, I may be able to suggest more. -Kiyoshi Kiyoshi Watanabe __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
[no subject]
Probably you might want to see http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2 FAQ is the best place to start. -Kiyoshi Kiyoshi Watanabe > If I hadn't already exhausted resources I would not have made this post in > the first place. I have tried 3 different versions of apache, searched > through previous postings, used search engines etc. bought 2 books on apache > and have been attempting to get this going for almost 2 months now. > > I'm glad you're amused by my frustration here. > > If there is anyone out there that is willing to submit a serious response to > this I would appreciate it greatly. > > Regards, > > Ian Newlands > > > - Original Message - > From: "Dave Paris" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: "Ian Newlands" <[EMAIL PROTECTED]> > Sent: Thursday, August 21, 2003 11:58 AM > Subject: Re: virtual hosting > > > >geeze. is it that time of the month already for this question? seems like > >it was just yesterday when it was asked last .. maybe I'm just thinking of > >the other 100,000 times it was asked. > > > >in all seriousness, this dead horse has been beaten so many times on this > >list there isn't even a carcass left to hit at this point. please go dig > >through the mail list archives to see why name-based virtual hosts don't > >work with SSL. > > > >yes, that's a flippant answer. no, you're not likely to get a reply any > >more serious. > > > >-dsp > > > >On Wednesday, Aug 20, 2003, at 22:09 US/Eastern, Ian Newlands wrote: > > > > > I am currently running about 15 virtual hosts using name based on port > > >80, and 1 virtual host using SSL. > > > > > > My SSL host is currently working with the following: > > > > > > > > > > > > However I want to change this to the IP based hosting for this host, > > >allowing me to then add more SSL based virtual hosts on this setup, so > I > >tried changing this to the following: > > > > > > > > > > > > By doing this my SSL virtual host stops working altogether. > > > > > > I try the following to debug it on a remote machine: > > > > > ># openssl s_client -connect 203.xxx.xxx.xxx:443 > > >CONNECTED(0003) > > >27604:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > > >protocol:s23_clnt.c:475: > > > > > > I do the exact same thing on the local machine and it responds with a > > >valid SSL response. > > > > > > Can anyone suggest might be wrong here? > > > > > > Regards, > > > > > > Ian Newlands > > > > > > _ > > > Hotmail is now available on Australian mobile phones. Go to > > >http://ninemsn.com.au/mobilecentral/signup.asp > > > > > > __ > > > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > > > User Support Mailing List [EMAIL PROTECTED] > > > Automated List Manager[EMAIL PROTECTED] > > > > > > > > > > > _ > Hot chart ringtones and polyphonics. Go to > http://ninemsn.com.au/mobilemania/default.asp > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Certificate verification problem (required client certificate)
Hello, I have seen the similar questions posted on the openssl mailing list before, but I have not seen much discussion. One thing that you may want to try to upgrade the version of the openssl itself, but I have no clue that applies to your problem. Why don't you post this question on the openssl mailing list?, hopoing to get that somebody solves the question since then. -Kiyoshi Kiyoshi Watanabe > Hello, > > I posted this question already some days ago, but did not yet receive any > hint. Does really no-one have any idea what could be the problem? > > --- > > I'm having a strange problem with Apache 2.0.45, mod_ssl with openssl > 0.9.6i (and possibly a factor also tomcat 4.1.27 server, client IE6 with > Java 1.4 plugin from Sun). > > The web-server should run all applications only over SSL and with client > certificate verification enabled. > > So I set up all the necessary configuration, including server and client > certificates (our company has it's own internal CA), and moved three > different applications from the non-SSL to the SSL virtual-host. > Everything works fine, the applications can access the "environment > variables", where the user-ID coming from the certificate is stored, in > order to authenticate the users and provide user-specific content. One of > the working applications is PHP based, another one is JSP based, so via > Tomcat. (only explaining this so that it is clear the whole server > combination including the SSL setup seems to be right in principal). > > However the 4th application doesn't work. > > The fourth application is not JSP, but a Servlet/Applet combination. > > What happens when accessing the page is that the "index.html" downloads to > the client, but then the applet should be retrieved by the browser > (IE/Java plug-in), but the JAVA Plug-In just says "applet not found", and > in the web-server error file (put in INFO) I see the following: > > [Tue Aug 05 18:56:52 2003] [info] Connection to child 4 established > (server esdsv07.my.com:443, client 115.191.1.8) > [Tue Aug 05 18:56:52 2003] [info] Seeding PRNG with 136 bytes of entropy > [Tue Aug 05 18:56:52 2003] [info] SSL library error 1 in handshake (server > esdsv07.my.com:443, client 115.191.1.8) > [Tue Aug 05 18:56:52 2003] [info] SSL Library Error: 336105671 > error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not > return a certificate No CAs known to server for verification? > [Tue Aug 05 18:56:52 2003] [info] Connection to child 4 closed with > abortive shutdown(server esdsv07.my.com:443, client 115.191.1.8) > [Tue Aug 05 18:56:52 2003] [info] Connection to child 69 established > (server esdsv07.my.com:443, client 115.136.126.30) > [Tue Aug 05 18:56:52 2003] [info] Seeding PRNG with 136 bytes of entropy > [Tue Aug 05 18:56:53 2003] [info] SSL library error 1 in handshake (server > esdsv07.my.com:443, client 115.136.126.30) > [Tue Aug 05 18:56:53 2003] [info] SSL Library Error: 336105671 > error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not > return a certificate No CAs known to server for verification? > [Tue Aug 05 18:56:53 2003] [info] Connection to child 69 closed with > abortive shutdown(server esdsv07.my.com:443, client 115.136.126.30) > > > I know, normally this "peer did not return a certificate" indicates that > either my browser does not have a certificate (which it has) or that the > certificate can not be verified by the server due to a missing CA > certificate (which it has). If one of these or both problems were there, > the other three applications would not work as well, right? But they do! > > Any ideas? > > If I switch on debug level, I get even more info (which does not tell me a > lot more). First there is a verification/handshake on client certificate A > (successful) and then there is something about a certificate B? what > is this about? What is certificate A and B? > >Thanks in advance > > Herbert > > Debugging info: > > [Tue Aug 05 19:14:46 2003] [info] Loading certificate & private key of > SSL-aware server > [Tue Aug 05 19:14:46 2003] [info] Init: Requesting pass phrase from dialog > filter program (/opt/hpws/apache/conf/passPhrase.dialog) > [Tue Aug 05 19:14:46 2003] [debug] ssl_engine_pphrase.c(499): encrypted > RSA private key - pass phrase requested > [Tue Aug 05 19:14:48 2003] [info] Configuring server for SSL protocol [Tue > Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(436): Creating new SSL > context (protocols: SSLv2, SSLv3, TLSv1) > [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(553): Configuring > client authentication > [Tue Aug 05 19:14:48 2003] [debug]
Re: Any tools to test https+mod_ssl ???
Hi I think that the following may help you. openssl s_client -connect localhost:443 -state -debug Please Refer to the FAQ in detail (www.modssl.org) -Kiyoshi Kiyoshi Watanabe > Hi All. > Further to my earlier comments that httpd + mod_ssl seems to be ignored by > Netscape 7.1 > After logging-in and accepting the certificate, 7.1's liitle lock remains > open and says I am transmitting in clear text. > Yet Netscape 6.2, MSIE5 and Mozilla all accepted the certificate and they > say the transmission is encrypted. > Are there any tools available to test the transmission ??? > Cheers. > :-) > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: But why does it work now : SSL throws SSL23_GET_SERVER_HELLOerror
Hi arthur, > I think that works ! > Instead of > [ssl] # openssl s_client -connect localhost:443 -state -debug > I key in > [ssl] # openssl s_client -connect 192.168.100.10:443 -state -debug > and it worked, no SSL23_GET_SERVER_HELLO error, why is that ??? I looked at your conf and realize that the conf was OK. However, your were accessing to the localhost, which was different from your virtual host. You can have the SSL when you access to the virtual host directive in which you specify that the ssl engine is on. The error happends when you access to the location in which you do not specify that the ssl engine is on. Probably someone else can answer this better than I do. > I am still *VERY CONCERNED* that the output from TCPDUMP contains human > readible data (admittedly you won't be able to get much out of that ). > Its nothing like the plain text http transmission, try it out ! I am not sure which data you are talking about. Transmission data is encrypted after the handshake stage completes. -Kiyoshi Kiyoshi Watanabe > > - Original Message - > From: "Kiyoshi Watanabe" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, August 08, 2003 06:44 AM > Subject: Re: FRUSTRATION : SSL throws SSL23_GET_SERVER_HELLO error > > > > > > Hello, > > > > did you test the openssl command using your IP instead of localhost? > > > > openssl s_client -connect your-ip-here:443 -state -debug > > > > Or why don't you change the VirtualHohost to _default_ temporarily and > > see how it goes. > > > > -Kiyoshi > > Kiyoshi Watanabe > > > > > > > > > > Problem #1: your OpenSSL doesn't have the error messages loaded so > you're > > > > getting a rather non-descriptive error message. No big deal, it just > > > > means you have to look harder to find out what the error means. > > > How to I load them in order to get a more meaningful description ??? > > > I've recompiled Apache 2.0.40 several times from scratch with following > > > additional options: > > > > ./configure --with-mpm=worker --enable-so --enable-rewrite --enable-ssl --wi > > > th-ssl=/path/to/openssl --enable-proxy --auth_digest > > > > > > > > > > Problem #2: SSL23_GET_SERVER_HELLO:unknown protocol: - now I bet if > you > > > > looked at the debug dump you'd see something very similar to: > > > > - 3c 21 44 4f 43 54 59 > > > which was mentioned in one of those links the other guy sent you. > It's > > > > telling you that that's what it received from the server. You'll > notice > > > > that " unencrypted. > > > Indeed, this is the whole output : > > > CONNECTED(0003) > > > write to 0809D018 [0809D060] (124 bytes => 124 (0x7C)) > > > - 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... > . > > > 0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 > .f.. > > > 0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 > ...e..d. > > > 0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 > .c..b..a..`. > > > 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 > [EMAIL PROTECTED] > > > 0050 - 00 00 06 00 00 03 04 00-80 02 00 80 5c ec 7c 7c > \.|| > > > 0060 - 60 b1 2a 84 93 cf ba f5-87 dc 22 63 27 83 c7 16 > `.*..."c'... > > > 0070 - f0 68 eb 8b 33 43 57 05-e8 5e a1 ef .h..3CW..^.. > > > read from 0809D018 [080A25C0] (7 bytes => 7 (0x7)) > > > - 3c 21 44 4f 43 54 59 > > SSL_connect:error in SSLv2/v3 read server hello A > > > 1565:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > > > protocol:s23_clnt.c:460: > > > > > > > So this tells you that your web server is in fact speaking plain HTTP > on > > > > port 443 rather than HTTPS. You probably do not have "SSLEngine on" > for > > > > that virtual host. > > > This defies purpose. Following is an excerpt from httpd.conf with only > those > > > bits that I believe are relevant . What I done that's wrong : > > > (httpd.conf) > > > > > > ServerName www.saysit.com.hk:80 > > > # > > > > > > # Some MIME-types for downloading Certificates and CRLs > > >AddType application/x-x509-ca-cert .crt > > >AddType application/x-pkcs7-crl.crl > >
Re: high-grade vs low-grade encryption with MD5 and DES
Hi, I never see 4096 bits keys used in the SSL transactions. I once see the key in the root CA in the natioanl PKI initiative in one country under very restrictive usage with customized application. I am just wondering if the market is moving to use such a longer bits key. -Kiyoshi Kiyoshi Watanabe > Practicality : do not use 4096 bits server side private key. No, not even > 2048. > Key size larger than 1024 is not supported by those bollocky client > browsers. Netscape and MSIE4 come to mind. > Regards, > Arthur Chan > > - Original Message - > From: "Dave Paris" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, August 11, 2003 07:34 PM > Subject: RE: high-grade vs low-grade encryption with MD5 and DES > > > > The "5 minutes" I mentioned doesn't implicitly refer to the amount of time > > needed to crack the ciphertext, but more the type of data and the amount > of > > time it needs to be protected. > > > > A couple examples: > > > > Example 1: > > A password which will only work for the next ten minutes only needs to be > > protected by encryption capable of rendering the text sufficiently > scrambled > > for that 10 minute duration. This might mean it would take an attacker 1 > > minute to obtain the ciphertext and get it into a state where it can be > > cryptanalyzed. Four or five minutes to determine the cipher used. Then > the > > attacker is left with only 3 or 4 minutes to break the cipher if they need > > one minute to actually use the password. So, how strong do you need > > encryption in this case? Only long enough to hold out against a 3 to 4 > > minute attack. > > > > Example 2: > > A "sealed" court case which is mandated to be sealed for 20 years needs to > > be protected by a cipher capable of using a large enough keyspace to keep > a > > sustained attack against the data at bay for that 20 years. > > > > Herein lies the challenge in the practical utilization of cryptography... > > how do we know what will protect data for 20 years? We don't. So we make > > educated guesses. We make compromizes. We use "best-available". In the > > example of the password above, 56 bit DES would be a reasonable choice. > > It's fast, but weak - yet strong enough to keep that password encrypted > for > > the two or three - heck, six, minutes it would be attacked. (this is not > to > > say that one should use the weakest available cipher for any given problem > > set! 3DES, AES, or Blowfish would be a much better choice in any case.) > In > > the example of the sealed court records, we're not worried about > transaction > > speed or decryption speed so an asymmetric cipher capable of utilizing a > > 4096 bit (or larger!) private key is much more appropriate. > > > > Kind Regards, > > -dsp > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Arthur Chan > > Sent: Sunday, August 10, 2003 6:39 AM > > To: [EMAIL PROTECTED] > > Subject: Re: high-grade vs low-grade encryption with MD5 and DES > > > > > > This is really symptomatic of our industry, isn't it? We seen to be our > own > > worse enemy. > > Back in 95, it took that French student days to crack the 40-bit codes. > Now > > we are talking about minutes... its disheartening. Merde. I really wonder > > how some of those MS sites survive these days... > > > > - Original Message - > > From: "Dave Paris" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, August 11, 2003 06:16 PM > > Subject: Re: high-grade vs low-grade encryption with MD5 and DES > > > > > > > "compromised" is probably a poor word to use, "pointlessly weak" is > > > more accurate. If you're going to use SSL and you're dealing with data > > > that needs to be protected longer than 5 minutes, use 128bit SSL. > > > > > > -dsp > > > > > > On Sunday, Aug 10, 2003, at 02:25 US/Eastern, Arthur Chan wrote: > > > > > > > Hi all. > > > > Verisign currently has a discount on both a high grade (128bits) SSL > > > > encrypted and a low grade (40bits) SSL encrypted certificates. The > > > > former is > > > > priced at US$895 and the latter at US$1395. > > > > I noticed some sites also present Verisign certificates with > low-grade, > > > > 54-bits encryption from their Microsoft
Re: FRUSTRATION : SSL throws SSL23_GET_SERVER_HELLO error
Hello, did you test the openssl command using your IP instead of localhost? openssl s_client -connect your-ip-here:443 -state -debug Or why don't you change the VirtualHohost to _default_ temporarily and see how it goes. -Kiyoshi Kiyoshi Watanabe > > Problem #1: your OpenSSL doesn't have the error messages loaded so you're > > getting a rather non-descriptive error message. No big deal, it just > > means you have to look harder to find out what the error means. > How to I load them in order to get a more meaningful description ??? > I've recompiled Apache 2.0.40 several times from scratch with following > additional options: > ./configure --with-mpm=worker --enable-so --enable-rewrite --enable-ssl --wi > th-ssl=/path/to/openssl --enable-proxy --auth_digest > > > > Problem #2: SSL23_GET_SERVER_HELLO:unknown protocol: - now I bet if you > > looked at the debug dump you'd see something very similar to: > > - 3c 21 44 4f 43 54 59 > which was mentioned in one of those links the other guy sent you. It's > > telling you that that's what it received from the server. You'll notice > > that " Indeed, this is the whole output : > CONNECTED(0003) > write to 0809D018 [0809D060] (124 bytes => 124 (0x7C)) > - 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... . > 0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f.. > 0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d. > 0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`. > 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 [EMAIL PROTECTED] > 0050 - 00 00 06 00 00 03 04 00-80 02 00 80 5c ec 7c 7c \.|| > 0060 - 60 b1 2a 84 93 cf ba f5-87 dc 22 63 27 83 c7 16 `.*..."c'... > 0070 - f0 68 eb 8b 33 43 57 05-e8 5e a1 ef .h..3CW..^.. > read from 0809D018 [080A25C0] (7 bytes => 7 (0x7)) > - 3c 21 44 4f 43 54 59 SSL_connect:error in SSLv2/v3 read server hello A > 1565:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:460: > > > So this tells you that your web server is in fact speaking plain HTTP on > > port 443 rather than HTTPS. You probably do not have "SSLEngine on" for > > that virtual host. > This defies purpose. Following is an excerpt from httpd.conf with only those > bits that I believe are relevant . What I done that's wrong : > (httpd.conf) > > ServerName www.saysit.com.hk:80 > # > > # Some MIME-types for downloading Certificates and CRLs >AddType application/x-x509-ca-cert .crt >AddType application/x-pkcs7-crl.crl >SSLSessionCache dbm:logs/ssl_scache >SSLSessionCacheTimeout 300 >SSLMutex file:logs/mutex >SSLRandomSeed startup builtin >SSLRandomSeed connect builtin > > ### Section 3: Virtual Hosts > Listen 80 > Listen 443 > NameVirtualHost 192.168.1.3 > > ServerName www.saysit.com.hk > ServerAdmin [EMAIL PROTECTED] > DocumentRoot /var/www/html > ErrorLog /usr/local/apache2/logs/saysit_error.log > CustomLog /usr/local/apache2/logs/saysit_access.log common > SetEnvIf User-Agent ".MSIE.*"\ >nokeepalive ssl-unclean-shutdown \ >downgrade-1.0 force-response-1.0 > JkMount /saysit ajp13 > JkMount /saysit/* ajp13 > > # > > > ServerName demo.saysit.com.hk > ServerAdmin [EMAIL PROTECTED] > DocumentRoot /home/nicole/MyDocument/public_html > ErrorLog /usr/local/apache2/logs/nicole_error.log > CustomLog /usr/local/apache2/logs/nicole_access.log common > >SSLEngine on >SSLCipherSuite > ALL:!ADH:!EPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL >SSLCertificateFile /usr/share/ssl/server.crt >SSLCertificateKeyFile /usr/share/ssl/server.key > SSLVerifyClient require will prompt the client to select a > certificate when browsing demo.saysit > > JkExtractSSL on > JkHTTPSIndicator HTTPS > JkSESSIONIndicator SSL_SESSION_ID > JkCIPHERIndicator SSL_CIPHER > JkCERTSIndicator SSL_CLIENT_CERT > JkMount /saysit ajp13 > JkMount /saysit/* ajp13 > > > > > > Problem #3: You mentioned trying to get name-based vhosts to work with > > SSL. You must realize that this doesn't work right in the general case. > > Please see http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2 . > Yes, I read that document and I do want to provide both http and https on a > single server with one single IP address (I am NAT-ting on router with one > external ip - does that matter?) &g
