How to import self signed certificate as trusted certificate ?
Hi all. I've created a self-signed certificate for testing purposes. I would like to import that into my IE5 and Ntescape7.1 browsers as trusted certificate so that the browser will accept the applet requests implicitly. Can someone point me in the right direction please i.e. read-ups, howto documentation, etc? Also this: my applet can access and display jpeg images butjava console throws the typical "Access Denied" error when I try to access a local notepad.txt file. HTML's, applets, jpegs and text files are all in the same directory on the server, I find it astounding that the applet cannot access its own text files, co-located in exactly the same directory without being a "signed applet", which brings me back to the purpose of this email... Does anyone find this a bit over the top? TIA :-)
Re-direct in vhost
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]
howto fossick around in archive
Hiya. How does one get to the archive to look around ? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SET payload factor ???
Hiya. How's it going Dave ? Remember we were talking about ATM packet and payload factor ? U mentioned something like payload to o/head @ 48/5. Were u talking about S.E.T. ? Am I looking at the right thing for very *high* volumn, short duration, 24x7 operations ? There's actually a small box inside those atms to capture the tx's when the db of the acquirer bank is down and depending on the card, issuance is almost guaranteed and the risk carried by the issuer bank. I don't know what they are now for IBM atms, but last few years there is a slow trend towards MS, scary thought. I think (meaning I don't know fore sure) SET is the smart card version with a chip. Relatively common in Hong Kong, don't know about USA. Wish theres a vpn here. - Original Message - From: Dave Paris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 22, 2003 10:37 AM Subject: Re: On Thursday, Aug 21, 2003, at 21:53 US/Eastern, Ian Newlands wrote: Dave Thank you for your reply, it was most enlightening and yes I will re-assess my future as a human being. Hopefully that statement somehow makes you feel better about yourself. [...] Get over yourself. I went out of my way to make it COMPLETELY CLEAR that I was not intending my comments as any sort of insult or other attack on your intelligence or worth as a person. -dsp [once again, I'm reminded why I stopped contributing to listservs a few years back] __ 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: configuration question
Hi Boyle, I've been debating with myself over whether to encrypt everything, that's a cogent argument you have offered. I have a few questions myself : (1) assuming an openssl encrypted packet is bigger than a plain text one, would mod_gzip shrink it significantly to warrant the effort? (2) and would that slow down the client browser display of content ? On the other hand, with these new 1GHz+ P4 desk- and lap-tops around, maybe not. - Original Message - From: Boyle Owen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 04:49 PM Subject: RE: configuration question -Original Message- From: Henrik Bentel [mailto:[EMAIL PROTECTED] I have a web app which serves both static and non static content, both secure and unsecure(https and http). Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. To add to Cliff's comment about browsers complaining about the mix of secure an insecure content there is a genuine security reason for *not* doing what you propose. Put yourself in the position of a crook who has gained access to the datastream flowing into your SSL server. As you are probably aware, all encryption ciphers can be cracked by a brute force attack (making repeated attempts at guesssing the key). Hopefully, the time-to-crack will be long, but you don't know how fast the crook's computer is. If he works for the NSA, it might be very fast indeed. If you serve all content via SSL, he has no idea which packets are important and which are just images etc. so he has to crack everything. If you decide to save a teeny bit of processing on the server by encrypting only the important things, he then sees lots of en clair packets (containing image data etc.) which he can safely ignore and only a few occasional nuggets of encrypted data which he can be sure are worth cracking. Thus he can focus his efforts on these. Therefore, you make life easy for the cracker by highlighting the packets that are worth cracking! In other words, the best place to hide a leaf is in the forest. You shouldn't need to worry about the processing load of the SSL encryption. If it is slowing your server, then, frankly, your server is not powerful enough to serve the traffic you have - get more memory, upgrade the chipset, do whatever is necessary to get up to speed. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. But, I don't want to generate absolute URLs on the fly to link to non-secure static content. What I want is to make request to certain urls less secure such that processing is faster. For example, I have a directory called art, which is just a defined alias for a directory. Is there a way to make ssl processing for this directory less restrictive than for the generic requests to the virtual host so that processing is faster? Home someone can help Henrik Bentel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Swiss Exchange. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Swiss Exchange. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière de la SWX Swiss Exchange. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. __ 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)
Re: configuration question
dependent on how much compression you're getting. If you can take a 100K document and compress it to 25K, that's a 75% reduction in the amount of data SSL needs to encrypt and reduces the number of packets from about 66 to around 16 - again, not including the SSL handshake/setup and general TCP setup/teardown. If you're bogging down your server with all the SSL transactions, look at investing in a SSL accelerator. If your business model depends on both security *and* performance, then the cost (starting around 20K$USD) should be easily justified. But that's the subject of another mail and I've got some coffee getting cold over here. ;-) Hope this didn't glaze your eyes over. :-) Best~ -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Boyle Owen Sent: Tuesday, August 19, 2003 7:02 AM To: [EMAIL PROTECTED] Subject: RE: configuration question -Original Message- From: Arthur Chan [mailto:[EMAIL PROTECTED] Hi Boyle, I've been debating with myself over whether to encrypt everything, that's a cogent argument you have offered. I have a few questions myself : (1) assuming an openssl encrypted packet is bigger than a plain text one, Why would you assume this? Essentially; encrypted_text = f(plain_text, key) where f() is a mathematical function. I guess the 2nd law of thermodynamics (entropy increases) would tend to cause the output to increase but not necessarily by much. In the simple case of a substitutional cipher, the encrypted text would be precisely the same size as the plain text. would mod_gzip shrink it significantly to warrant the effort? Zipping algorithms work by replacing repetitive sequences in the input with shorter instructions to regenerate them (e.g. 1000 blue pixels - 1 blue pixel x 1000). Compression works best with highly structured input data (bitmaps, WAV files, human language etc). With random data, it can't make much difference and will even cause the file to grow! (try repeatedly zipping a file to see this happening). (2) and would that slow down the client browser display of content ? Unzipping requires the client to have winzip - not a default on a windows client! Probably this would slow the whole thing down. Remember that SSL is well-defined on the web and all recent browsers contain fast and effective SSL software - I would trust it to do its job and not try to re-invent the wheel. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. On the other hand, with these new 1GHz+ P4 desk- and lap-tops around, maybe not. - Original Message - From: Boyle Owen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 04:49 PM Subject: RE: configuration question -Original Message- From: Henrik Bentel [mailto:[EMAIL PROTECTED] I have a web app which serves both static and non static content, both secure and unsecure(https and http). Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. To add to Cliff's comment about browsers complaining about the mix of secure an insecure content there is a genuine security reason for *not* doing what you propose. Put yourself in the position of a crook who has gained access to the datastream flowing into your SSL server. As you are probably aware, all encryption ciphers can be cracked by a brute force attack (making repeated attempts at guesssing the key). Hopefully, the time-to-crack will be long, but you don't know how fast the crook's computer is. If he works for the NSA, it might be very fast indeed. If you serve all content via SSL, he has no idea which packets are important and which are just images etc. so he has to crack everything. If you decide to save a teeny bit of processing on the server by encrypting only the important things, he then sees lots of en clair packets (containing image data etc.) which he can safely ignore and only a few occasional nuggets of encrypted data which he can be sure are worth cracking. Thus he can focus his efforts on these. Therefore, you make life easy for the cracker by highlighting the packets that are worth cracking! In other words, the best place to hide a leaf is in the forest. You shouldn't need to worry about the processing load of the SSL encryption. If it is slowing your server, then, frankly, your server is not powerful enough to serve the traffic you have - get more memory, upgrade the chipset, do whatever is necessary to get up to speed. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. But, I don't want to generate absolute URLs on the fly to link to non-secure static content. What I want is to make request to certain urls less secure
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]
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]
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]
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]
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: 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
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
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]
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. 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
FRUSTRATION : SSL throws SSL23_GET_SERVER_HELLO error
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 !DOCTY 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 !DOCTY is the first few bytes of a standard html page 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 !DOCTY 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 # IfModule mod_ssl.c # 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 /IfModule ### Section 3: Virtual Hosts Listen 80 Listen 443 NameVirtualHost 192.168.1.3 VirtualHost 192.168.1.3:80 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 /VirtualHost # IfDefine SSL VirtualHost 192.168.1.3:443 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 IfModule mod_ssl.c 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 /IfModule JkExtractSSL on JkHTTPSIndicator HTTPS JkSESSIONIndicator SSL_SESSION_ID JkCIPHERIndicator SSL_CIPHER JkCERTSIndicator SSL_CLIENT_CERT JkMount /saysit ajp13 JkMount /saysit/* ajp13 /VirtualHost /IfDefine 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?) __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
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]
But why does it work now : SSL throws SSL23_GET_SERVER_HELLO error
Hi Yoshi.
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 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 !
- 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 !DOCTY
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 !DOCTY is the first few bytes of a standard html page
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 !DOCTY
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
#
IfModule mod_ssl.c
# 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
/IfModule
### Section 3: Virtual Hosts
Listen 80
Listen 443
NameVirtualHost 192.168.1.3
VirtualHost 192.168.1.3:80
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
/VirtualHost
#
IfDefine SSL
VirtualHost 192.168.1.3:443
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
IfModule mod_ssl.c
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
/IfModule
JkExtractSSL on
JkHTTPSIndicator HTTPS
JkSESSIONIndicator SSL_SESSION_ID
JkCIPHERIndicator SSL_CIPHER
JkCERTSIndicator SSL_CLIENT_CERT
JkMount /saysit ajp13
JkMount
Browser specific OpenSSL mod_ssl problem !
Hi All. Help. Netscape is driving me to drinks! Problem : Netscape 7.1 will not redirect from http://my.first.dom to https://my.secure.dom, claims it is transmitting in clear text (rather than encrypted). Objective : from first web-site, create a linik to a secure web-site inside index.html using an anchor e.g. A HREF=https://my.secure.dom;ClickMe/A Set up : Apache2 httpd + mod_ssl + Tomcat + Oracle. Tomcat holds java servlets. Apache server has applets communicating with servlets. What works : Everything works just fine using W98+MSIE5 or W98+Netscape6.2 or Linux+Mozilla. What doesn't work : Using Netscape 7.1, When I key in the URL my.first.dom, it takes me to the web-site. When I click on the link to my.secure.dom, which does indeed take me to the secure site, it presents the logon screen and the certificate. I logged on and accepted the certificate. Normally in Netscape 6.2, the tiny lock located in bottom right side of screen should be closed and shows the certificate when I click on it. But in 7.1, the lock is NOT CLOSED and it says that the transmission is in clear text for all to see. However, if I key in the URL : https://my.secure.dom, the little lock closes and shows the certificate. ... [code] (httpd.conf) ... Listen 192.168.100.1:80 Listen 443 NameVirtualHost 192.168.100.1 VirtualHost 192.168.100.1:80 ServerName my.first dom ... /VirtualHost # I added following redirect in the hope Netscape7.1 would work - didn't! VirtualHost 192.168.100.1:80 Server my.secure.dom Redirect /index.html https://my.secure.dom/index.html /VirtualHost # as far as MSIE5 and Mozilla are concerned, they only need the following lines to work properly VirtualHost ServerName my.secure.dom ... IfModule mod_ssl.c ... blablabla /IfModule ... VirtualHost [/code] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Any tools to test https+mod_ssl ???
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]
test subscription - don't reply
testing subscription __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
