Re: Successful installed Apache+modssl/openssl+php/mysql
Addressed to: [EMAIL PROTECTED] Mark Lo [EMAIL PROTECTED] ** Reply to note from Mark Lo [EMAIL PROTECTED] Wed, 31 May 2000 00:41:57 +0800 Hi, I have been successfully installed Apache+modssl/openssl+mysql/php4, but php only works when "https" is used. I also want to enable php in "http". I have followed the HowTo from http://www.linuxguruz.org/index.html?state=PHPTipstopic=PHP1901 and my configure scripts is as follows: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --enable-versioning --with-mysql --with-ldap --with-ftp --with-gd --disable-debug --enable-memory-limit=yes --enable-tract-vars I think you need to look in your httpd.conf. Where do you enable php? I suspect you will find it inside the VirtualHost www.whatever.com:443. You either need to move it above, and OUTSIDE all VirtualHost blocks, or put it in every one that needs PHP. Rick __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
IE 4.01 [german]
Hay everybody, I'm having a strange prob with my Apache/openSSL/mod_ssl: Versions: Apache 1.3.12 OpenSSL: 0.9.5a ModSSL: 2.6.2 AND 2.6.4 (for Apache 1.3.12) the following occures. Any german Internet Explorer in the Version Numbers 4.01.x up to 5.0 no matter if it has an 40bit or 128bit Chipher, is showing my Certificate (I'm my own CA). Looks good. If you accept the Cert the Browser shows: "Seite kann nicht angezeigt werden." Which means site can't be display. I attached some snips of my system configuration. I created my own CA key, making a own Server key and the corresponding Certs. I everything like it is said in the howto's and tutorials. Whatever I do. These f***ing german versions of IE (And only this) don't work. It's working with every other Browser very well btw. My Testurl is: https://nuwonder.ghb.fh-furtwangen.de The following ist the config in httpd.conf: --snip IfModule mod_ssl.c SSLPassPhraseDialog builtin SSLSessionCacheTimeout 300 SSLRandomSeed startup builtin SSLLog logs/ssl_engine_log SSLLogLevel info SSLProtocol ALL SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL /IfModule VirtualHost 141.28.228.130:443 ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/htdocs/es ServerName nuwonder.ghb.fh-furtwangen.de CustomLog /var/log/apache/es_ssl_log common ErrorLog /var/log/apache/es_ssl_error_log SSLEngine on SSLCertificateFile /etc/apache/ssl.nuwonder/nuwonder.crt SSLCertificateKeyFile /etc/apache/ssl.nuwonder/nuwonder.key.unsecure SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclear-shutdown /VirtualHost --snip The following is the ssl_log entry I get. --snip [28/May/2000 17:53:01 13180] [info] Seeding PRNG with 0 bytes of entropy [28/May/2000 17:53:02 13180] [info] Connection: Client IP: 141.28.228.194, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits) [28/May/2000 17:53:02 13180] [info] Connection to child 7 closed with standard shutdown (server nuwonder.ghb.fh-furtwangen.de:443, client 141.28.228.194) [28/May/2000 17:53:07 13135] [info] Connection to child 1 established (server nuwonder.ghb.fh-furtwangen.de:443, client 141.28.228.194) [28/May/2000 17:53:07 13135] [info] Seeding PRNG with 0 bytes of entropy [28/May/2000 17:53:07 13135] [info] Spurious SSL handshake interrupt[Hint: Usually just one of those OpenSSL confusions!?] --snip Does anybody know what to do? I'm pretty close at giving up. Regards roman Roman Gerteis - c o m p u t e r n e t w o r k i n g [FHF] ICQ: 42160345 | Mail: [EMAIL PROTECTED] --- $ man woman No manual entry for woman __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: Apache+modssl/openssl+mysql/php4
There is a good article on this in devshed.com... The Soothingly Seamless Setup of Apache, SSL, MySQL, and PHP in PHP by Israel Dennis. http://www.devshed.com/Server_Side/PHP/SoothinglySeamless/ Lots of feedback as well on this setup... Hope it helps. Phil Deacon -Original Message- From: Mark Lo [mailto:[EMAIL PROTECTED]] Sent: Monday, May 29, 2000 9:20 AM To: ssl-modssl Subject: Apache+modssl/openssl+mysql/php4 Hi, Is there any documentation about how to install Apache+modssl/openssl+mysql/php4, I have tried to follow the INSTALL manual which comes with modssl package, but my installation is not successfull. Is there any other documentation about how to install the above packages. Thanks Mark __ 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]
Failed to Generate 512 Private Key Problem
Dear Support Officer I would like to install an Apache with Jrun and SSL modules on Sun Solaris 2.6 environment. The 'Failed to generate temporary 512 bit ROSA private key' is shown on the ssl_engine_log when the Apache is being activated. From the attached file, you will see the installation procedures (Apache SSl Jrun Installation1.doc), the configuration file of Apache (httpd.cont) and error logs (ssl_engine_log and error_log). Sincean error message, d21_PrivateKey.bio has previous declarationis shown during configuring and compiling the Apache, the 'declaration of d21_PrivateKey_bio' in 'apache_1.3.9/src/modules/ssl/ssl_util_ssl.c' file has been remark. (Pls refer to step 4 of'Apache SSl Jrun Installation1.doc' for details) Would you help me to resolve this problem? Thanks Wallace Wai System AnalystInternet PRO LimitedPenthouse Chuang's Hunghom Plaza83 Wuhu StreetKowloon Tel: (852) 2303 0099 Fax: (852) 2303 0098Web Site: http://www.iproasia.com Email: [EMAIL PROTECTED] Apache SSL Jrun Installation1.doc ssl_engine_log httpd.conf error_log
Fwd:new vulnerability in Netscape effectively disables SSL server auth
From: Kevin Fu [EMAIL PROTECTED] Reply-To: Kevin Fu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [linux-delhi] new vulnerability in Netscape effectively disables SSL server auth Date: Fri, 26 May 2000 09:51:24 EDT [For all you dudes who use Netscape to make lakhs of rupees worth of online purchases... watch out! -- Raju] -BEGIN PGP SIGNED MESSAGE- Introduction This vulnerability defeats SSL server authentication in Netscape 4.73 and earlier versions. This is a new vulnerability unrelated to CERT advisory 2000-5. However, it has a similar devastating effect: destroying SSL server authentication. Under certain conditions, users can no longer trust the authenticity of SSL server certificates in Netscape. This new vulnerability makes Netscape's SSL implementation as insecure as DNS. If you are victimized by this attack, then you may unknowingly divulge private information such as credit card numbers, personal data, passwords to online financial services, or other sensitive information to an adversary masquerading as what you think is a trusted SSL server. Reported to Netscape: May 15, 2000 Reported to CERT: May 17, 2000 Publicly announced: May 26, 2000 Problem === Within one Netscape session, if a user clicks on "continue" in response to a "hostname does not match name in certificate," then that certificate is incorrectly validated for future use in the Netscape session, REGARDLESS of the hostname or IP address of other servers that use the certificate. Exploit === My web server has a certificate signed by a trusted certificate authority. For the purposes of this exploit, the example web servers below share the same certificate and private key. Official name: snafu.mit.edu Host address: 18.152.0.102 Official name: snafu.fooworld.org Host address: 18.152.0.102 Official name: www.nscl.org Host address: 18.152.0.131 1. Play the part of the innocent user. Visit https://snafu.mit.edu/ with any version on Netscape (minus the Personal Security Manager). When the dialog warning appears, you click continue because you do not intend to give private information to this web server. You just want to access the page with confidentiality enabled, whether or not the server is authentic. Note that you have asked to accept this certificate for this hostname, snafu.mit.edu, even though the certificate belongs to snafu.fooworld.org. 2. Now play the part of the adversary. Simulate DNS poisoning. Add an entry to /etc/hosts (UNIX), c:\windows\hosts.sam (Windows98), or c:\winnt\system32\drivers\etc\hosts (Windows NT) that reads: www.the-site-you-want-to-spoof.com 18.152.0.131 This will redirect your www.the-site-you-want-to-spoof.com requests to another server, www.nscl.org. The www.nscl.org server happens to use the same certificate as snafu.mit.edu. 2. Schach. Time to switch back to playing the innocent user. Visit https://www.the-site-you-want-to-spoof.com/. If your browser allows you to visit this site without a warning, you have been duped into believing you are talking to a trusted SSL web server. Analysis If the ILOVEYOU virus has taught us anything, it's taught us that the general user population can be easily fooled by seemingly innocent requests. This vulnerability is a prime example. By following a link to an SSL server that has a certificate with an incorrect hostname, all future SSL connections in the Netscape session are made no more secure than DNS. It seems that the "Certificate Name Check" warning will mark a certificate as valid for any hostname or IP address in the future. In this way, if an adversary tricks a user into accepting an invalid certificate at a seemingly benign site, the user can then be tricked if he/she ever visits a malicious site using the same certificate. A benign "continue" click on https://snafu.mit.edu/ might end up taking away server authentication from visiting https://www.a-site-that-you-give-private-info.com/ that has poisoned DNS. Note, I have only tested this with server certificates signed by a certificate authority trusted by Netscape. This attack may be less powerful if the malicious server certificate is merely self-signed. Furthermore, the security community has many examples showing that DNS is not secure at all. For instance, a teenager recently defaced the RSA.COM site by an attack against a DNS server. It should be trivial to attack targeted individuals and not difficult to attack general users at large. Here are some imagined but unimplemented ways that might fool a user into accepting an invalid certificate: * Javascript/Java which references an HTTPS URL. * Users just clicks. * Hide the warning window with a pop-up window. * Email with embedded HTTPS. * Embed HTTPS images in a web page. * VBS ILOVEYOU variant virus attachment that appends to hosts.sam and adds certificate to browser's certificate database. Here are some ways one might affect DNS: * Add
(APache + SSL + virtual-IP) problem
Hi, I have some troubles with the use of Apache + mod_ssl + virtual-IP. It works fine for http. For https, there are problems : It actually works with two VIPs, but if I add another one, it doesn't work anymore. Anyone has an idea ? Thanks Jeff Dr. Jean-Francois Beraud Jean-Francois Beraud, PhD Directeur technique NetDirect NetDirect CTO tel: 33-4-93 00 03 00 fax: 33-4-93 00 03 09 [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [PHP3] Successful installed Apache+modssl/openssl+php/mysql
Did you restart the port 80 httpd? I have been successfully installed Apache+modssl/openssl+mysql/php4, but php only works when "https" is used. I also want to enable php in "http". I have followed the HowTo from http://www.linuxguruz.org/index.html?state=PHPTipstopic=PHP1901 and my configure scripts is as follows: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --enable-versioning --with-mysql --with-ldap --with-ftp --with-gd --disable-debug --enable-memory-limit=yes --enable-tract-vars Repeat: The above scripts only bring php to work in "Https", I would like to enable php to work in "Http". Thank you so much, Mark -- PHP 3 Mailing List http://www.php.net/ To unsubscribe, send an empty message to [EMAIL PROTECTED] To subscribe to the digest, e-mail: [EMAIL PROTECTED] To search the mailing list archive, go to: http://www.php.net/mailsearch.php3 To contact the list administrators, e-mail: [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Authentication with certificates only of clients on untrusted hosts
On Tue, May 30, 2000 at 02:41:50PM -0600, Joel Smith wrote: Hi, I've read chapter 5 of the modssl docs (the section on Client Authentication and Access Control), but can find quite what I'm looking for. I'm trying to find an easy way to require certificate based authentication to apache only from machines outside our firewall, whereas, those within can authenticate with a username/password pair. I've done this easily enough to qmail with the TLS patch and to imaps via stunnel. If I could get apache w/ modssl to do the same, I'd be set. I don't want to make two different areas of the site (like the "/secure/area" described in the docs) Anyone have a good idea? I suppose potentially I could have a virtual host which those outside could point to, and another inside, but I'd rather not. Users are so hard to train. :-) I might be missing what you're trying to do - but if I'm reading this right, then all you want to do is to allow plain http access from one location and require SSL + client certs from all other ip's? Then it really isn't that hard at all - just make Apache listen on plain HTTP and limit access to that based on ip, and then also make an HTTPS/ client cert protected virtual host that just has the same DocumentRoot. You can then choose to let HTTPS users enter their passwords as they would with plain HTTP or you could use SSLOptions +FakeBasicAuth (see http://www.modssl.org/docs/2.6/ssl_reference.html#ToC21). Alternatively you could set up a solution like: http:[EMAIL PROTECTED] vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Apache+modssl+openssl (Hong Kong)
Hi, I have checked with international law crypto survery, I still can't find out whether I can use apache+modssl+openssl in Hong Kong or not. And I am using modssl for commercial purpose, do I need to purchase a support. Thanks Mark __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: pointers to a European CA (128 bit) recognizable by both NS IE?
Yes, I had heard about Thawte, but Verisign has just bought Thawte and I wanted to see if I have other options. I got some clarification back from my contact in the UK... Yes, Verisign bought Thawte a few months ago (announced in December, finalised in February). However the two companies are still operating largely as separate brands, i.e. you can still get Thawte certs through us (and I expect this to continue for the foreseeable future) and Verisign certs through BT Trustwise. There's a possibility that we (Herald) may also be able to resell Verisign certs but that's still very nebulous. Hope this helps, James. begin:vcard n:Lyon;James tel;pager:24-hour contact via Work number tel;cell:+44 (7973) 824857 tel;fax:+44 (24) 7670 2501 tel;home:Please use Cellular number. tel;work:+44 (24) 7670 2500 x-mozilla-html:TRUE url:http://www.aztec.co.uk/ org:Business IT Research Ltd t/a Aztec Business Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Managing Director adr;quoted-printable:;;Enterprise House=0D=0ACourtaulds Way;Coventry;;CV6 5NX;UK fn:James Lyon end:vcard
SV: IE 4.01 [german]
If it any solace to you, I can tell you it does not work with a Swedish IE either. My English IE5 on W2k reads it. -Ursprungligt meddelande- Från: Roman Gerteis [mailto:[EMAIL PROTECTED]] Skickat: den 28 maj 2000 18:57 Till: [EMAIL PROTECTED] Ämne: IE 4.01 [german] Hay everybody, I'm having a strange prob with my Apache/openSSL/mod_ssl: Versions: Apache 1.3.12 OpenSSL: 0.9.5a ModSSL: 2.6.2 AND 2.6.4 (for Apache 1.3.12) the following occures. Any german Internet Explorer in the Version Numbers 4.01.x up to 5.0 no matter if it has an 40bit or 128bit Chipher, is showing my Certificate (I'm my own CA). Looks good. If you accept the Cert the Browser shows: "Seite kann nicht angezeigt werden." Which means site can't be display. I attached some snips of my system configuration. I created my own CA key, making a own Server key and the corresponding Certs. I everything like it is said in the howto's and tutorials. Whatever I do. These f***ing german versions of IE (And only this) don't work. It's working with every other Browser very well btw. My Testurl is: https://nuwonder.ghb.fh-furtwangen.de The following ist the config in httpd.conf: --snip IfModule mod_ssl.c SSLPassPhraseDialog builtin SSLSessionCacheTimeout 300 SSLRandomSeed startup builtin SSLLog logs/ssl_engine_log SSLLogLevel info SSLProtocol ALL SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL /IfModule VirtualHost 141.28.228.130:443 ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/htdocs/es ServerName nuwonder.ghb.fh-furtwangen.de CustomLog /var/log/apache/es_ssl_log common ErrorLog /var/log/apache/es_ssl_error_log SSLEngine on SSLCertificateFile /etc/apache/ssl.nuwonder/nuwonder.crt SSLCertificateKeyFile /etc/apache/ssl.nuwonder/nuwonder.key.unsecure SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclear-shutdown /VirtualHost --snip The following is the ssl_log entry I get. --snip [28/May/2000 17:53:01 13180] [info] Seeding PRNG with 0 bytes of entropy [28/May/2000 17:53:02 13180] [info] Connection: Client IP: 141.28.228.194, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits) [28/May/2000 17:53:02 13180] [info] Connection to child 7 closed with standard shutdown (server nuwonder.ghb.fh-furtwangen.de:443, client 141.28.228.194) [28/May/2000 17:53:07 13135] [info] Connection to child 1 established (server nuwonder.ghb.fh-furtwangen.de:443, client 141.28.228.194) [28/May/2000 17:53:07 13135] [info] Seeding PRNG with 0 bytes of entropy [28/May/2000 17:53:07 13135] [info] Spurious SSL handshake interrupt[Hint: Usually just one of those OpenSSL confusions!?] --snip Does anybody know what to do? I'm pretty close at giving up. Regards roman Roman Gerteis - c o m p u t e r n e t w o r k i n g [FHF] ICQ: 42160345 | Mail: [EMAIL PROTECTED] --- $ man woman No manual entry for woman __ 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: 56-bit MSIE 4.01
To all those people who asked ... I finally found that patching my MSIE4.01 to handle 128-bit fixed my problems... Hope this helps, James. begin:vcard n:Lyon;James tel;pager:24-hour contact via Work number tel;cell:+44 (7973) 824857 tel;fax:+44 (24) 7670 2501 tel;home:Please use Cellular number. tel;work:+44 (24) 7670 2500 x-mozilla-html:TRUE url:http://www.aztec.co.uk/ org:Business IT Research Ltd t/a Aztec Business Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Managing Director adr;quoted-printable:;;Enterprise House=0D=0ACourtaulds Way;Coventry;;CV6 5NX;UK fn:James Lyon end:vcard
Re: Authentication with certificates only of clients on untrusted hosts
On Tue, May 30, 2000 at 02:41:50PM -0600, Joel Smith wrote: I've read chapter 5 of the modssl docs (the section on Client Authentication and Access Control), but can find quite what I'm looking for. I'm trying to find an easy way to require certificate based authentication to apache only from machines outside our firewall, whereas, those within can authenticate with a username/password pair. I've done this easily enough to qmail with the TLS patch and to imaps via stunnel. If I could get apache w/ modssl to do the same, I'd be set. I don't want to make two different areas of the site (like the "/secure/area" described in the docs) Anyone have a good idea? I suppose potentially I could have a virtual host which those outside could point to, and another inside, but I'd rather not. Users are so hard to train. :-) Mads Toftum wrote: I might be missing what you're trying to do - but if I'm reading this right, then all you want to do is to allow plain http access from one location and require SSL + client certs from all other ip's? Then it really isn't that hard at all - just make Apache listen on plain HTTP and limit access to that based on ip, and then also make an HTTPS/ client cert protected virtual host that just has the same DocumentRoot. You can then choose to let HTTPS users enter their passwords as they would with plain HTTP or you could use SSLOptions +FakeBasicAuth (see http://www.modssl.org/docs/2.6/ssl_reference.html#ToC21). Alternatively you could set up a solution like: http:[EMAIL PROTECTED] I need the local users to use HTTPS also, since they will be authenticating with username/password. I don't like stuff flying around in the clear. That's why it's trickier. Is their a directive that says "Require cert unless originating from IP address xxx.xxx.xxx.xxx"? Your idea is similar to the different virtual host solution I proposed. i.e. give one url to internal people, another to external, and the internal vhost will only talk to LAN users, the external will require a cert, but since our whole company is passing around intranet URLs all the time, it's not practical to train users to send both urls, or for people to figure out why a given URL isn't working for them. I wan one host, https, that can decide if a cert is needed to authenticate based on originating IP address. Let me see if I understand the solution based on the post to the modperl list. We give people a URL to a machine that is proxying trafic. That machine checks the IP address, then based on whether they originate from the outside or the inside, it redirects them to a site which does or doesn't require a cert. Is that it? I guess that would work too. I'd still rather be able to do it with a directive in the conf file on a singe vhost. Later, Joel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
re-generate certificate request key
Hi, I would like to know how to re-generate a certificate request key. I am using Redhat linux 6.2 and compiling apache+modssl/openssl+php/mysql. I only can generate a certificate request key during the installation, but I did make something wrong in it, as a result, I am not able to get the test certificate from verisign. I need to re-generate my certificate request key. I am using the the instruction from http://www.linuxguruz.org/index.html?state=PHPTipstopics=PHP1901 to compile my server. The main problem is that openssl seems didn't install on the server from the above instructions, so I can't be able to re-generate my request key using openssl command. Thank you so much, Mark __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Bad Protocol Version Number ???
Greetz from Alaska, Every time I start httpsd I'm asked for the Pass Phrase, given the ok and the daemon is started. All the SSL domains work except one. Even though I am asked for the Pass Phrase and it replies with OK but I can't connect. Below is the error I get in the ssl_engine_log file when I try to connect to the site. When I change their CRT and KEY file to the the main servers (server.crt/key) the site works great. Any ideas? Thanks Dan Please reply to [EMAIL PROTECTED] [31/May/2000 12:11:56] [error] Unable to configure server private key for connection (OpenSSL library error follows) [31/May/2000 12:11:56] [error] OpenSSL: error:14080074:SSL routines:SSL3_ACCEPT:bad protocol version number [31/May/2000 12:11:56] [error] Unable to configure server private key for connection (OpenSSL library error follows) [31/May/2000 12:11:56] [error] OpenSSL: error:14080074:SSL routines:SSL3_ACCEPT:bad protocol version number __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
SSL Tunneling over HTTP - unidentified TCP data
I am trying to understand the http CONNECT method. I've found no documentation that really gets down to the nitty-gritty details (I know it's got to be out there somewhere) and have resorted to sniffing packets. But the browser is sending a packet with TCP data that I can not identify. In the scenario I'm trying the browser is configured to use an HTTPS proxy (Apache 1.3.12, mod-ssl 2.6.4, openssl-0.9.4) and issues an HTTPS request for a page. The packets I see are (three way TCP handshake omitted) browser -- proxy: (tcpdata) CONNECT . proxy content-server: three-way TCP handshake browser -- proxy (tcpdata) HTTP/1.0 200 Connection established. browser -- proxy (here's the one I don't understand - I was expecting "client hello") (tcpdata) 80 46 01 03 00 00 2d 00 00 00 ...and more for 72 bytes.. proxy -- content-server (forwards same packet to server, as expected) proxy -- content-server (tcpdata) 16 03 00 04 ca 02 ...and more for 1231 bytes... this is I believe the server hello protocol 22 - SSL handshake version 3.0 length 04ca (1226 - 5 byte header) type 2 - server hello browser -- proxy same server hello message When I connect directly to the server (and don't use a proxy) I see packets containing the SSL handshake starting with a client hello. I have a book SSL and TLS Essentials (by Stephen Thomas) that I'm using to parse what I think are the SSL packets, but I can't seem to make sense of this packet that the browser is sending after receiving the Connection Established message. Is this packet a client hello? Can an SSL handshake start with a server hello? Can anyone point me in the right direction? Thanks in advance. Deborah Hansknecht Sandia National Laboratories [EMAIL PROTECTED] 505 844-6532 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Urgent: remove password from server cert?
In a sudden (and late) moment of epiphany, I just realized (while writing a note to our CSA to please put the new server's startup in the machines boot cycle) that when we reboot (*every* monday morning in the wee hours) it's not terribly likely that anyone's going to be around to feed the password to the startup query. This really needs to be automated. Help? =o) Paul = Friends are those who, when you must inconvenience them, are less bothered by it than you. ;o] __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Urgent: remove password from server cert?
(Ralf: Documentation bug, see below for details) This is addressed in the FAQ: http://www.modssl.org/docs/2.6/ssl_faq.html#ToC31 . "When you can be sure that your server is secure enough you perform two steps: 1. Remove the encryption from the RSA private key (while perserving the original file): $ cp server.key server.key.org $ openssl rsa -in server.key.org -out server.key 2. Make sure the server.key file is now only readable by root: $ chmod 400 server.key Now server.key will contain an unencrypted copy of the key. If you point your server at this file it will not prompt you for a pass-phrase. HOWEVER, if anyone gets this key they will be able to impersonate you on the net. PLEASE make sure that the permissions on that file are really such that only root or the web server user can read it (preferably get your web server to start as root but run as another server, and have the key readable only by root)." Ralf: document bug, it says "preferably get your webserver to start as root but run as another server". That should read '...as another user". --- Mat Butler, Winged Wolf [EMAIL PROTECTED] SPASTIC Web Engineer SPASTIC Server Administrator Begin FurryCode v1.3 FCWw5amrsw A- C+ D H+++ M+[servercoder] P+ R++ T+++ W Z++ Sm++ RLCT/M*/LW* a cl/u/v+ !d e- f h++ iwf+++ j p-+ sm++ End FurryCode v1.3 On Wed, 31 May 2000, Paul wrote: In a sudden (and late) moment of epiphany, I just realized (while writing a note to our CSA to please put the new server's startup in the machines boot cycle) that when we reboot (*every* monday morning in the wee hours) it's not terribly likely that anyone's going to be around to feed the password to the startup query. This really needs to be automated. Help? =o) Paul = Friends are those who, when you must inconvenience them, are less bothered by it than you. ;o] __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ __ 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]
