high-grade vs low-grade encryption with MD5 and DES
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/IIS servers. However I cannot find a 54-bits certificate in www.verisign.com/products/site/commerce/index.html Is this 54-bits affair only for Microsoft / IIS ??? Is low-grade encryption with 40 and 54 bits considered "compromised" ??? Are there any finance/insurance industry standard requiring a 128 bits, high-grade encryption ??? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: high-grade vs low-grade encryption with MD5 and DES
Hi Yoshi. I have been looking around and haven't seen 4096 in use either. I think most companies have settled for the standard by default ie 1024/128 and it would be a lot of work to change that. What do they do under those circumstances ? Revoke the old certificate and issue new one ? You can do your own survey, simply throw up the log-on screen for the major banks (and second tier ones), then look at their certificates. They all have 1024/128. I can't see a long live for 1024/128, maybe a few more years. Something is bound to happen. Also, I doubt whether it is practical, seeing how some (slightly) older browsers cannot handle that. Arthur - Original Message - From: "Kiyoshi Watanabe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 11, 2003 08:39 PM Subject: 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: > > > > > > >
RE: Certificate verification problem (required client certificate)
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] ssl_engine_init.c(1096): CA certificate: /O=my.com/OU=IT Infrastructure/C=US/O=MY Company/CN=MY Primary Class 2 Certification Authority [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(611): Configuring permitted SSL ciphers [!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL] [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(739): Configuring RSA server certificate [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(778): Configuring RSA server private key [Tue Aug 05 19:14:49 2003] [info] Loading certificate & private key of SSL-aware server [Tue Aug 05 19:14:49 2003] [info] esdsv07.my.com:443 reusing existing RSA private key on restart [Tue Aug 05 19:14:51 2003] [info] Configuring server for SSL protocol [Tue Aug 05 19:14:51 2003] [debug] ssl_engine_init.c(436): Creating new SSL context (protocols: SSLv2, SSLv3, TLSv1) [Tue Aug 05 19:14:51 2003] [debug] ssl_engine_init.c
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] ssl_engine_init.c(1096): CA > certificate: /O=my.com/OU=IT Infrastructure/C=US/O=MY Company/CN=MY > Primary Class 2 Certification Authority > [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(611): Configuring > permitted SSL ciphers > [!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL] > [Tue Aug 05 19:14:
unique cipher-text
Hi, Does anyone know why using the req -new option from the same private key, twice does not generate a unique CSR? As an example: I have an existing private key. I then generate a CSR from it. Openssl req -new -key privakey.key -out csr.txt I then generate another CSR from the private key and use identical DN information. I can understand why the exponents and modules are the same.. because they are using the same private key, however why does the cipher text look the same? Isn't it suppose to be random? I have trying to find the answer at http://www.openssl.org/docs/ but cannot.. Basically, I'd like to know what is responsible for the cipher text output? and can it be randomized each time without changing the DN levels. Thanks, R __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: high-grade vs low-grade encryption with MD5 and DES
I wasn't [specifically] referring to SSL. In fact, the mere premise of passing data designated as "must be protected" for a 20 year timeframe over 128 bit SSL (with a 1024 bit client key) frightens me to the core. (If the encryption of this data was protecting *you* from [we'll go on a limb here and be dramatic] an crime organization with tens of millions of dollars to devote to discovering who turned them in to the Feds, would *you* want it sent over a 1024 bit SSL link?!) *THIS* is what's really wrong with the industry - we have people using technology in inappropriate situations. Too many who DO understand how to use it appropriately with the responsibilities, restrictions, and caveats that come with that understanding are either unable or unwilling to convince those in the position of "final decision maker" of just how WRONG certain applications/implementations actually are. Bottom line, if the available protocols & application cannot support the data protection requirements - DO NOT send the data over that link. For a baseline dissertation on key lengths for symmetric and asymmetric ciphers, please see: http://www.giac.org/practical/gsec/Lorraine_Williams_GSEC.pdf Additionally, RSA currently recommends 2048 bit keys for "extremely valuable keys". My gut says that knowing about devices like TWIRL, et al. make 2048 bit keys risky for long-term protection because God only knows what devices we *don't* know about. -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arthur Chan Sent: Sunday, August 10, 2003 7:52 AM To: [EMAIL PROTECTED] Subject: Re: high-grade vs low-grade encryption with MD5 and DES 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. > [...] > 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. [...] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
How to installing a "trusted" certificate in Netscape
Hi all. This may be a trivial question... I have signed my own ceritificate. How do I "install" that as a "trusted" certificate so that Netscape6 doesn't throw the warning screen that I have been presented with a certificate form an untrusted site. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
How does JSSE interact with OpenSSL ?
Hi All, Well it seems to me with java's URLConnection as distinct from HttpURLConnection, *some* data slip through un-encrypted. Oddly, only data declared as "text" e.g. Oracle's VARCHAR2, slip through into the Net in human readible form. First, I thought JSSE is part of the standard install for j2sdk1.4 , second I imagined that using URLConnection, somehow automagically the data will be encrypted by OpenSSL when going through apache mod_ssl. Does anyone know how JSSE and OpenSSL interact ??? I mean, the only way around this dilemma is to programmatically encrypt the data before sending it through openssl. Does that sound odd to anyone :-o ??? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
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]
Certificate verification problem (required client certificate)
Hello, I'm having a strange problem with Apache 2.0.45 / openssl 0.9.6 (and possibly tomcat 4.1.27). 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. However the 4th application doesn't work. One of the working applications is PHP, another also working application is JSP based, so using Tomcat. 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), but the JAVA Plug-In just says "applet not found", and in the web-server error file (put in INFO) I see the following errors.: [Tue Aug 05 18:56:52 2003] [info] Connection to child 4 established (server esds v07.bbn.hp.com:443, client 15.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 esdsv 07.bbn.hp.com:443, client 15.191.1.8) [Tue Aug 05 18:56:52 2003] [info] SSL Library Error: 336105671 error:140890C7:SS L 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 shu tdown(server esdsv07.bbn.hp.com:443, client 15.191.1.8) [Tue Aug 05 18:56:52 2003] [info] Connection to child 69 established (server esd sv07.bbn.hp.com:443, client 15.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 esdsv 07.bbn.hp.com:443, client 15.136.126.30) [Tue Aug 05 18:56:53 2003] [info] SSL Library Error: 336105671 error:140890C7:SS L 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 sh utdown(server esdsv07.bbn.hp.com:443, client 15.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, but they do! Now I was wondering if it could be an issue somewhere inbetween mod_ssl, mod_jk, Tomcat?? In principal the connector between Apache and Tomcat works, otherwise the JSP application would not work as well. That can be easily verified by inserting a bug in this configuration and voila, the JSP app stops working. Any ideas? thanks in advance Herbert PS: if I switch on debug level, I get even more info, which does not help me, but it first says something about client certificate A (success) and then something about a certificate B? what is this about? [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 filte r program (/opt/hpws/apache/conf/passPhrase.dialog) [Tue Aug 05 19:14:46 2003] [debug] ssl_engine_pphrase.c(499): encrypted RSA priv ate 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 cont ext (protocols: SSLv2, SSLv3, TLSv1) [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(553): Configuring client au thentication [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(1096): CA certificate: /O=my.com/OU=IT Infrastructure/C=US/O=MY Company/CN=MY Primary Class 2 Certification Authority [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(611): Configuring permitted SSL ciphers [!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL] [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(739): Configuring RSA serve r certificate [Tue Aug 05 19:14:48 2003] [debug] ssl_engine_init.c(778): Configuring RSA serve r private key [Tue Aug 05 19:14:49 2003] [info] Loading certificate & private key of SSL-aware server [Tue Aug 05 19:14:49 2003] [info] esdsv07.my.com:443 reusing existing RSA pr ivate key on restart [Tue Aug 05 19:14:51 2003] [info] Configuring server for SSL protocol [Tue Aug 05 19:14:51 2003] [debug] ssl_engine_init.c(436): Creating new SSL cont ext (protocols: SSLv2, SSLv3, TLSv1) [Tue Aug 05 19:14:51 2003] [debug] ssl_engine_init.c(553): Configuring client au thentication [Tue Aug 05 19:14:51 2003] [debug] ssl_engine_ini
It's alive : thank-you all, for the assistance
I have my Apache2+mod_ssl talking OpenSSL and working with my Tomcat now. Thanks to all of you who helped, especially to [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: SSL throws SSL23_GET_SERVER_HELLO error
Please see following links http://www.mail-archive.com/[EMAIL PROTECTED]/msg16205.html http://forums.devshed.com/archive/15/2001/11/4/25897 Hope they help. Regards, Nauman ___ Citibank N.A., 111 Wall St., New York, NY Ph: +1-212-657-1070 (w), +1-718-951-0508 (h) Fax: +1-212-657-1645 -Original Message- From: Arthur Chan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 5:10 AM To: [EMAIL PROTECTED] Subject: SSL throws SSL23_GET_SERVER_HELLO error Hi All. When I run the following line command : [ssl] # openssl s_client -connect localhost:443 -state -debug I get this error message : ... 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: ... Looking at line 460 of the source, it is exactly that error, no further clues available. Does anyone know more about it and want to help out ??? 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]
FRUSTRATION : SSL throws SSL23_GET_SERVER_HELLO error
Hiya I followed the discussion on those links, but it was not conclusive for me. It would seem that I have got both apache2.0.40 + mod_ssl talking with OpenSSL, using name-based vhosts. I have the certificate installed and self-signed. However [ssl] # openssl s_client -connect localhost:443 -state -debug still throws this sticky error : 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: I am down to checking the source code (reveals nothing much other than it is an error), and blindly changing things in httpd.conf... Frustrating - Original Message - From: "Nauman, Ahmed [IT]" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 07, 2003 10:07 AM Subject: RE: SSL throws SSL23_GET_SERVER_HELLO error Please see following links http://www.mail-archive.com/[EMAIL PROTECTED]/msg16205.html http://forums.devshed.com/archive/15/2001/11/4/25897 Hope they help. Regards, Nauman ___ Citibank N.A., 111 Wall St., New York, NY Ph: +1-212-657-1070 (w), +1-718-951-0508 (h) Fax: +1-212-657-1645 -Original Message- From: Arthur Chan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 5:10 AM To: [EMAIL PROTECTED] Subject: SSL throws SSL23_GET_SERVER_HELLO error Hi All. When I run the following line command : [ssl] # openssl s_client -connect localhost:443 -state -debug I get this error message : ... 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: ... Looking at line 460 of the source, it is exactly that error, no further clues available. Does anyone know more about it and want to help out ??? 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] __ 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 > > >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 > > > > > > # > > > > > > > > >
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/IIS servers. However I cannot > > find a > > 54-bits certificate in > > www.verisign.com/products/site/commerce/index.html > > Is this 54-bits affair only for Microsoft / IIS ??? > > Is low-grade encryption with 40 and 54 bits considered "compromised" > > ??? > > Are there any finance/insurance industry standard requiring a 128 bits, > > high-grade encryption ??? > > > > __ > > 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] __ 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: 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/IIS servers. However I cannot > > > > find a > > > > 54-bits certificate in > > > > www.verisign.com/products/site/commerce/index.html > > > > Is this 54-bits affair only for Microsoft / IIS ??? > > > > Is low-grade encryption with 40 and 54 bits considered "compromised" > > > > ??? > > > > Are there any finance/insurance industry standard requiring a 128 > bits, > > > > high-grade encryption ??? > > > > > > > > __ > > > > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > > > > User Support Mailing List [EMAIL PROTECTED] > > > > Automated List Manager[EMAIL PROTECTED] > > > > > > > > > >
