Re: SSL proxy
It seem like you might be confusing shared infrastructure with single ip. As others have said, you need a distinct address for each SSL-enabled httpd or proxy, although they can reside on the same hardware. A good example of this is the typical configuration for larger server farms. You find multiple High Availability load balancers in the DMZ for both http and https using something like ha/keepalived for linux. These proxy the incoming request back into private address space. The SSL proxies terminate the SSL connection and broker the request on behalf of the user and everything goes to the private address space in plain http. This allows each of the _real_ webservers to achieve better performance since the SSL overhead is not present. While you can use Apache as an SSL-terminating proxy, I find I get better performance, lower memory utilization and easier configuration using Pound ( http://www.apsis.ch/pound/ ). Using keepalived, I have multiple public IP addresses floating between several hosts and pound binds https to those addresses. Hope that adds a bit of additional clarity, Dave Cuesta Gilles sent forth: So what about this ? *MULTIPLE CN (SAN) SERVER CERTIFICATES* This type of certificate (also called /Subject Alternative Name/ (SAN) ) enables to secure not only one website but a large number of sites (a list of sites) hosted on a shared infrastructure (server with multiple names, reverse proxy). Ideal to secure multiple brands of a corporation. One certificate per hardware is required. http://www.tbs-certificats.com/index.html.en __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Will these name based virtual host work with SSL?
a) no. b) each virtual host would need a separate address - you cannot use SSL with name-based virtual hosts. Best~ -d [EMAIL PROTECTED] wrote: If in my httpd.conf file I have numerous virtual hosts defined with include files like: Include /usr/local/apache/conf/conf.d/devl00.conf Include /usr/local/apache/conf/conf.d/devl01.conf Include /usr/local/apache/conf/conf.d/devl02.conf Include /usr/local/apache/conf/conf.d/devl03.conf If I SSL enable the entire server in the main httpd.conf file, would I be able to access each virtual host on port 443 like https://devl02.mydomain.com/? I believe I would be able to access https://www.mydomain.com securely as well. I guess the question is, can you SSL enable the entire server, and access each virtual host via port 443? -Thanks __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Will these name based virtual host work with SSL?
ok, with my notes and Aaron's, there *is* something you can do. If you create the certificate for www.domain.com, you can rewrite HTTPS requests to something like: https://www.domain.com/dev100/ https://www.domain.com/dev101/ ::tosses 0.02$USD on the table:: -d Aaron Dalton wrote: [EMAIL PROTECTED] wrote: If in my httpd.conf file I have numerous virtual hosts defined with include files like: Include /usr/local/apache/conf/conf.d/devl00.conf Include /usr/local/apache/conf/conf.d/devl01.conf Include /usr/local/apache/conf/conf.d/devl02.conf Include /usr/local/apache/conf/conf.d/devl03.conf If I SSL enable the entire server in the main httpd.conf file, would I be able to access each virtual host on port 443 like https://devl02.mydomain.com/? I believe I would be able to access https://www.mydomain.com securely as well. I guess the question is, can you SSL enable the entire server, and access each virtual host via port 443? This comes up so often that it is in the Apache SSL FAQ. You may not have more than one SSL host on any given IP/Port combination. http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Will these name based virtual host work with SSL?
re-read my previous mail on rewriting the URL. You *might* want to do something further, like: http://dev101.domain.com/secure/ gets rewritten to: https://www.domain.com/dev101/ mod_rewrite is your friend. ok, so it's more like a thug that clubs you over the head before patting you on the back and handing you a beer - but it's still your friend. -d [EMAIL PROTECTED] wrote: Thanks for the info. From what I gather I will not be able to access the virtual hosts via SSL since they are name based, unless I use the mod_gnutl apache module. Now my question is, if I purchase only 1 SSL certificate, and I SSL enable the main server like: https://www.mydomain.com/ Then of cousre, none of the virtual hosts like http://devl01.mydomain.com or http://devl01.mydomain.com would be accessible via SSL. Would this scneria work with just the main server SSL enabled and all the virtual hosts accessed via port 80? -Thanks -- Original message -- From: Aaron Dalton [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If in my httpd.conf file I have numerous virtual hosts defined with include files like: Include /usr/local/apache/conf/conf.d/devl00.conf Include /usr/local/apache/conf/conf.d/devl01.conf Include /usr/local/apache/conf/conf.d/devl02.conf Include /usr/local/apache/conf/conf.d/devl03.conf If I SSL enable the entire server in the main httpd.conf file, would I be able to access each virtual host on port 443 like https://devl02.mydomain.com/? I believe I would be able to access https://www.mydomain.com securely as well. I guess the question is, can you SSL enable the entire server, and access each virtual host via port 443? This comes up so often that it is in the Apache SSL FAQ. You may not have more than one SSL host on any given IP/Port combination. http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2 -- Aaron Dalton | Super Duper Games [EMAIL PROTECTED] | http://superdupergames.org __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Adding SSL on-the-fly programmatically
Ok, so script the chown'ing and permissioning on import. It's still easier on an embedded system to install apache as SSL-capable and only enable when desired, rather than jumping through flaming hoops and loading up the mod_ssl module when needed. Embedded devices are designed around the KISS principle. The more complex you make it, the surer you are to be getting loads of support calls. Best~ -dsp SANDER SMITH wrote: You're right, what I'm asking for is not normal and I understand it. However, your suggestions make some assumptions about the normalcy of the environment that we're dealing with which just isn't the reality of my situation. The project I'm working on is not to simply secure an e-commerce site running on some big server hardware. I'm looking at apache running on some embedded platform. Users will not be people who understand what chown is, but will be content by just pushing buttons on the front panel of the device. Because of how the device is being deployed, I can even assume that everything can be run under root to simplfy things. So given that this is not a normal case, any ideas on how to proceed? Dave Paris [EMAIL PROTECTED] wrote: This seems about 180deg from normal. Install Apache with mod_ssl. Start it without invoking SSL .. if you get a certificate, you'll want to hand-walk it into the right place, chown it to root, and make it perm'd to 0400 anyway .. then a quick graceful stop and startssl .. *poof*, Bob's yer uncle. Best~ -d SANDER SMITH wrote: I'm looking to do something, but I'm not sure it's even possible. Maybe someone can steer me in the right direction. Let's say that I have a copy of apache running on my server. I also have a brand new SSL certificate that was signed by a CA. I'd like to write some code to programmatically enable SSL on the server by means of mod_ssl. When I think about the steps necessary, I need to: 1. Copy the mod_ssl files to the proper place. 2. Update the mod_ssl config files to point to my SSL certificate. 3. Update the apache config files to recognize and run mod_ssl 4. Cause apache to suddenly start to use mod_ssl Now steps 1,2, and 3 seem pretty straight forward. Step 4 is a huge handwave, and I'm hoping someone can give me some insight. Is it even possible? Does it require apache to be restarted? Is there some programmatic way to get apache to restart? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Apache mod_ssl and FIPS 140-2
http://csrc.nist.gov/cryptval/140-1/1401val2007.htm#733 Best~ -d [EMAIL PROTECTED] wrote: Does anyone know if the Apache v2.2.x implementation of OpenSSL mod_ssl is FIPS 140-2 validated? What version of OpenSSL is distributed with the current version of Apache? Any help is much appreciated… Thanks, *David Gerendas, **CISSP* McAfee, Inc. 949-297-5600 Main 949-860-3369 Direct 949-289-8677 Mobile [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Apache wont start with ssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Occasionally, /var/spool/clientmqueue can bite you as well. The filesystem will not show 100% used but you'll be out of inodes. (If that happens, you'll have loads of fun clearing it out ;-) Good Luck! - -dsp Andy Cravens wrote: Judging from the error message No space left on device sounds like some file system is full... maybe /tmp. The next time this happens open a shell window and type: df -k Check the output to see if one of your file systems is full. Look at /tmp and /swap specifically Ryan Forrester wrote: When attempting to start apache in SSL mode: $ /home/servers/apache_1.3.37/bin/apachectl startssl $ semget: No space left on device Rebooting the machine allows me to start apache once more.. but after a few days, apache wil fail and the same error occurs again, and the only way to resolve is to reboot. - Apache will start in mornal mode without a reboot. error_log doesnt contain any useful information to help troubleshoot the problem. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGDz62KmNPF3QynfQRAgjmAJ0XOdj2FH9O8oPRk9wD+IEEGgQHIwCfZmjc +urX+xVcjjO+b/XjbsSfz6c= =cMPQ -END PGP SIGNATURE- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Decrypting the HTTPS requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I typically use a SSL-terminating reverse proxy in the DMZ, like Pound, to terminate the SSL connection at the front door and send the request back into a private subnet over plain HTTP for IDS/IPS detection, clicktracking, etc. Best~ - -dsp Nikhil Kadu wrote: Hi Guys, Is it possible to decrypt the encrypted data in an HTTPS request/response while sitting in the Apache Proxy? Which functions of MOD_SSL and MOD_PROXY modules need to be tweaked to achieve this? Please let me know if somebody has done some related work. Best regards, Nikhil Kadu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFsOIOKmNPF3QynfQRAsGbAKCILyuzshFEcS2Kxec1Vqwx3BRPDgCfUWQ+ V+K12TOX32Jzmn2MszWgu2s= =22Uk -END PGP SIGNATURE- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Same old 405 Post not allowed error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, a) you never added the contents of your Location directive (i.e. with the following Location directives..) b) you don't specify *why* you need these, particularly given that you're using IP-based virtual hosts. (i.e. (which we really need)) Without this information, it's impossible to answer your question and I highly suspect that your solution lies with a minor reconfiguration. Kind Regards, - -dsp Mark Diggory wrote: Hello, I've been doing my research and can't find a solution for this issue, we have IP based virtual hosts with the following Location directives (which we really need) and are getting the 405 Post not allowed error. The issue does not seem to be addressed again for 3 years now. Is there a solution to this? http://marc.theaimsgroup.com/?l=apache-modsslm=104857625910336w=2 Here is my current configuration: Gentoo: 1.12.6 mod_ssl: 2.8.25-r10 apache:2.0.58-r2 mod_jk:1.2.19 tomcat: 5.5.20-r7 Thanks in advance for any advice, Mark R. Diggory ~ DSpace Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFsCiIKmNPF3QynfQRAomwAJ4pPBcfzWeeD93Q+YedPX8YV6ARMACfW4EZ 7277LvxtQRhQC8QzxBrE6h8= =Eqmr -END PGP SIGNATURE- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Mod_ssl and how to reduce overhead
I use Pound (http://www.apsis.ch/pound/) as an SSL-terminating reverse proxy .. on commodity hardware, it can handle - at least according to quotes from the field - up to around 400 conns/sec. It also affords you some additional firewalling in that you can put the SSL terminating accelerator in the DMZ and pass straight HTTP traffic to the backend without the client ever directly connecting to the web server/cluster. I also use keepalived to keep a pair of Pound proxies in a high-availability scenario. If you really need it, you could probably put up a HA/LVS cluster of Pound proxies up that terminate and proxy traffic for an entire web farm - if your traffic demands it. The other bonus is that by terminating SSL at the DMZ, your IDS/IPS system gets a chance to peek at the traffic. Pound does numerous other things as well (URL normalization, etc) .. head to the URL and have a good read. Best~ -d Pigeon wrote: Hello, I am trying to plan a system that can handle 10k-100k users. I am only using apache w/mod-ssl What should I look at to reduce overhead of bandwidth/cpu/mem? At what point should I look at ssl accelerators? Should I definitly look at clustering? Also.. I ahve heard about ssl session key caching, anyone know how much this will improve things? Any good resources I can read? thanks! Lee __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Multiple Virtual Servers with modssl
Jeffrey M. Johnson wrote: I am knew to this list and have spent many hours looking for an answer I am sure is probably right in front of my face. knew?! from a .edu address? ::boggle:: alas, I digress. I have a host that has 40 some virtual hosts associated with it, but only one of those hosts is configured for modssl. I know need to configure a second (and possible more) virtualhosts for modssl. No such thing as multiple hosts under one certificate. Use one certificate per virtual host. First, I am assuming this can be done. Bad assumption. It can't by virtue of the the design of SSL. Second, I can’t figure out how it can be done. See my previous answer. Any help would be appreciated. Search the archives. This one rears its ugly head fairly frequently. -dsp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
RE: Install Questions
First and foremost, if this is a world-accessable server, upgrade your
version of OpenSSL to the most recent available for RH7.3 (I'd also consider
upgrading to RH9.0 while you're at it). 0.9.6b has several security
vulnerabilities outlined at www.openssl.org. Also, use the most current
versions of Apache and mod_ssl.
.. that being said..
Generally speaking, the standard, non-DSO build can be summarized as such:
# build and install OpenSSL from source (http://www.openssl.org)
cd ${OPEN_SSL_SRC_DIR} ; CFLAGS=${CFLAGS} ./config -fPIC
make test
make install
# build mod_ssl/patch Apache source (http://www.modssl.org)
cd ${MOD_SSL_DIR}
CFLAGS=${CFLAGS} ./configure --with-apache=../${APACHE_SRC_DIR}
# build and install Apache from source (http://httpd.apache.org)
cd ${APACHE_SRC_DIR}
CFLAGS=${CFLAGS} SSL_BASE=../${OPEN_SSL_SRC_DIR}
./configure --enable-module=ssl
make
make install
# done..
There are numerous other configuration directives, but the above will build
a mod_ssl capable Apache instance for you.
Kind Regards,
-dsp
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bob Cohen
Sent: Monday, March 01, 2004 11:58 AM
To: [EMAIL PROTECTED]
Subject: Install Questions
Hi,
Please forgive the newbie questions, I'm a web designer bumbling my way
through system administration. I really did make an effort to search
the archives. :-) Time's running short to get this project done.
The box on which I'm working has RedHat 7.3 with openssl-0.9.6b-35.7
installed as an RPM.
[...]
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Re[2]: rse has beagle-a virus ?
As I suspected, none of these messages originate from Ralf. Just checking the original headers on the most recent batch of six I got overnight... from cruzeiro (cruzeiro.fisc.wwu.edu [140.160.220.200]) by master.modssl.org from CLS-TORG1010-27 (torg1010-27.its.vt.edu [128.173.44.191]) by master.modssl.org from CLS-TORG1010-24 (torg1010-24.its.vt.edu [128.173.44.188]) by master.modssl.org from CLS-TORG1010-30 (torg1010-30.its.vt.edu [128.173.44.194]) by master.modssl.org from woofie (A052105.N1.Vanderbilt.Edu [129.59.52.105]) by master.modssl.org from AdamBroughton (asdl00.ae.gatech.edu [130.207.39.100]) by master.modssl.org What this tells me is that someone realized the .edu addresses on the listserv were low hanging fruit. Nice job. Try partying less, studying more, and figure out how to keep yourself from being infected (on multiple fronts). [aside: pisses me off that I have to deal with spam from cracked/infected boxes from .edu domains ... I think I'm just going to reject all .edu-headered mail. it's a hugely sad commentary that people from institutions of *higher* education can't grasp the concept of DON'T CLICK ON F^KING ATTACHMENTS YOU'RE NOT EXPECING and USE A [EMAIL PROTECTED] A/V PACKAGE ALREADY, DAMNIT. I mean really, people.. you're shelling out a TON of money and you don't seem to be one lick smarter than Jimmy Joe-Jobber's mom who'll click on everything and anything since getting her PC two weeks ago. If you're as f%$king stupid as you appear to be, give it up .. save yourself the money and give your slot at school to someone else. There no shame in doing manual labor for a living. Society needs both ends of the spectrum. If you can't figure out the don't click stuff, I have no idea what you're going to do with number theory or algorithms (assuming you're in a CS program). I vote to kick the .edu's off the listserv until they prove they've got an intellectual agility quotient above that of a small soapdish. If this pisses off admins for .edu's, sorry .. life's a bitch, grab a helmet. The rest of us out in the real world have to deal with [l]users like this and keep our networks clean for the rest of the planet - you're no different... you just have a harder job that I certainly don't envy. Perhaps instituting a three strikes policy for students .. the first infection gets you a warning .. the second gets you booted off the school's network .. the third (meaning you violated both the 2nd AND 1st) gets you booted from school. Hrmm.. not a bad idea, I suppose. Anyway .. rant mode is now OFF.] Kind-ish Regards, -dsp :-) [...] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: rse has beagle-a virus ?
More likely a faked 'From' address. While possible, it's highly improbable that the source is actually Ralf's machine. I've routed my copies to /dev/null so I can't examine the headers to determine if the source address actually resides in Europe or not. Kind Regards, -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of madhon Sent: Friday, February 27, 2004 6:31 PM To: [EMAIL PROTECTED] Subject: rse has beagle-a virus ? just had a couple of copies of this come through from [EMAIL PROTECTED] ... someone needs to check their machine __ 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]
[moderator-request] Re: Your Contact Info
Will the moderator(s) be so kind as to killfile this user? Thanks, we get enough spam without it bypassing internal filters for important listservs like modssl-users. Kind Regards, -dsp On Tuesday, Nov 4, 2003, at 10:53 US/Eastern, Kevin Klawon wrote: image.tiff Kevin Klawon.vcf __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: ASN.1 Encoding errors
Wonder if this has anything to do with the recent repairs to the ASN.1 subsystem in OpenSSL. http://www.openssl.org/news/secadv_20030930.txt -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeffrey Burgoyne Sent: Wednesday, October 08, 2003 7:04 AM To: [EMAIL PROTECTED] Subject: Re: ASN.1 Encoding errors Hmm, just noticed something a bit more suspicious. The error does not come up every time for the same certs. It sometimes does not seem to come up at all. Jeff On Wed, 8 Oct 2003, Jeffrey Burgoyne wrote: Hi; I just upgraded an Apache server 1.3.26 with OpenSSL 0.9.7c and mod_ssl 2.8.9 from Openssl 0.9.6d. I now get the following errors : Server www.eac-trousse.ic.gc.ca:443 (RSA) Enter pass phrase: Server biotech.gc.ca:443 (RSA) 213659:error:0D094068:asn1 encoding routines:d2i_ASN1_SET:bad tag:a_set.c:179: 213659:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:946: 213659:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=RSA 213659:error:0D09A00D:asn1 encoding routines:d2i_PrivateKey:ASN1 lib:d2i_pr.c:96: Enter pass phrase: Server strategis.gc.ca:443 (RSA) 213659:error:0D094068:asn1 encoding routines:d2i_ASN1_SET:bad tag:a_set.c:179: 213659:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:946: 213659:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=RSA 213659:error:0D09A00D:asn1 encoding routines:d2i_PrivateKey:ASN1 lib:d2i_pr.c:96: Enter pass phrase: Server production.paymentnotification.ic.gc.ca:443 (RSA) Enter pass phrase: Server ip-pi.gc.ca:443 (RSA) Enter pass phrase: Server cbac-cccb.ca:443 (RSA) Enter pass phrase: Server corporations.ic.gc.ca:443 (RSA) Enter pass phrase: Server corporationscanada.ic.gc.ca:443 (RSA) 213659:error:0D094068:asn1 encoding routines:d2i_ASN1_SET:bad tag:a_set.c:179: 213659:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:946: 213659:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=RSA 213659:error:0D09A00D:asn1 encoding routines:d2i_PrivateKey:ASN1 lib:d2i_pr.c:96: Enter pass phrase: Ok: Pass Phrase Dialog successful. /usr/local/apache/bin/apachectl startssl: httpd started strategis The virtual hosts with the error still seem to work fine. Ideas? Jeffrey Burgoyne __ 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: Modssl wait background script to finish
A couple questions. Is this something like a SSL-protected web interface to an IMAP server (ref: your mention of port 143)? If so, are you accepting certain directives which are being passed on to the IMAP server (ref: start the script on port 143)? If this is the case, it sounds like what you're intending to do is start a fire and forget script .. not being concerned about the return value from the script. If that's the case, you may want to look at creating a IPC process of some sort that can be left to fend for itself after being started, allowing a response to get back to the user. Is this an accurate assessment of what you're trying to do? -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Vincent KERAVEC Sent: Monday, September 01, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Modssl wait background script to finish Hello, I've got a problem with modssl. When I run a script in background, the server doesn't respond to the browser who start the script on port 143 until the script finish. The server continue to reply to all other browser. I'm running Apache/2.0.40 (Red Hat Linux) with mod_ssl/2.0.40 and OpenSSL/0.9.7a. I'm also using client side authentication. Is there something to change in the ssl configuration to allow background process ? Thanks, Vincent KERAVEC ps : When i put modssl in loglevel debug the server seems to wait after this message : [Wed Aug 27 15:10:30 2003] [debug] /usr/src/build/250859-i386/BUILD/httpd-2.0.40/modules/ssl/ssl_engine_io.c(10 05): +-+ [Wed Aug 27 15:10:30 2003] [info] Initial (No.1) HTTPS request received for child 0 (server ***..***:443) __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: Modssl wait background script to finish
Someone with more PHP experience than I will need to address the use of exec() in the context of PHP, but were this Perl then exec() would stop the running Perl process after launching the external process - which would have the effect of stopping your running Perl script. Whether PHP operates similarly, I'm not sure (I don't do anything with PHP).. however this might be something to look into since (as I understand it) many of PHP's internals were borrowed from Perl originally. If this was Perl, you'd want either system(), open2(), open3(), or backticks. Good luck! -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Vincent KERAVEC Sent: Monday, September 01, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Re: Modssl wait background script to finish Thanks for your response, Sorry I mean 443 and not 143 :( I just want to run a bash script on the server. I launch the script whith : ?php exec (nohup ./script.sh /dev/null ); ? The page load successfully but when I follow a link the server didn't respond. If I use an other navigator the server respond normally. Vincent KERAVEC Dave Paris wrote: A couple questions. Is this something like a SSL-protected web interface to an IMAP server (ref: your mention of port 143)? If so, are you accepting certain directives which are being passed on to the IMAP server (ref: start the script on port 143)? If this is the case, it sounds like what you're intending to do is start a fire and forget script .. not being concerned about the return value from the script. If that's the case, you may want to look at creating a IPC process of some sort that can be left to fend for itself after being started, allowing a response to get back to the user. Is this an accurate assessment of what you're trying to do? -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Vincent KERAVEC Sent: Monday, September 01, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Modssl wait background script to finish Hello, I've got a problem with modssl. When I run a script in background, the server doesn't respond to the browser who start the script on port 143 until the script finish. The server continue to reply to all other browser. I'm running Apache/2.0.40 (Red Hat Linux) with mod_ssl/2.0.40 and OpenSSL/0.9.7a. I'm also using client side authentication. Is there something to change in the ssl configuration to allow background process ? Thanks, Vincent KERAVEC ps : When i put modssl in loglevel debug the server seems to wait after this message : [Wed Aug 27 15:10:30 2003] [debug] /usr/src/build/250859-i386/BUILD/httpd-2.0.40/modules/ssl/ssl_engine_io.c(1 0 05): +-+ [Wed Aug 27 15:10:30 2003] [info] Initial (No.1) HTTPS request received for child 0 (server ***..***:443) __ 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: [Fwd: mod_ssl compile problems]
of course, this is assuming the kerberos libs have been installed. :-) -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Orton Sent: Tuesday, August 26, 2003 4:27 PM To: Trevor Morrison Cc: [EMAIL PROTECTED] Subject: Re: [Fwd: mod_ssl compile problems] I am trying to compile in mod_ssl 2.8.15 into the apache1.3.28 source and using openssl-1.9.7a-2 installed from an RH RPM and I am getting the following error: ranlib libstandard.a === src/modules/standard === src/modules/ssl gcc -c -I../.. -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -I../../os/unix -I../../include -DLINUX=22 -DMOD_SSL=208115 -DMOD_PERL -DUSE_PERL_SSI -D_REENTRANT -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DUSE_HSREGEX -DEAPI -DEAPI_MM -DNO_DL_NEEDED `../../apaci` -DSSL_USE_SDBM -DSSL_ENGINE -DMOD_SSL_VERSION=\2.8.15\ mod_ssl.c In file included from /usr/include/openssl/ssl.h:179, from mod_ssl.h:116, from mod_ssl.c:65: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from mod_ssl.h:116, from mod_ssl.c:65: /usr/include/openssl/kssl.h:132: parse error before krb5_enctype ... You need to add -I/usr/kerberos/include to CFLAGS, use e.g. CFLAGS=-I/usr/kerberos/include ./configure --etc etc when building Apache. Regards, joe __ 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: SET payload factor ???
I was referring to Asynchronous Transfer Mode transport-layer protocol - typically used on WAN and long-haul links. Really doesn't have anything to do with SET or other applications. -d On Friday, Aug 22, 2003, at 00:51 US/Eastern, Arthur Chan wrote: 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. [...] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: CGI/SSL spec?
http://www.apache-ssl.org/docs.html#CGI but there is no RFC for SSL envvars that I'm aware of. mod_ssl offers a more complete list than is shown above. This can be found at: http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25 since the server is what's setting the environment variable, you need to go by the documentation you're working with. A good example of a popular, yet optional envvar is HTTP_REFERER .. this is a completely optional envvar left up to the browser's implementation team. So, to depend on this variable, you need to be positive of the client hitting your server. Likewise the SSL envvars. Regards, -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Philip Champon Sent: Friday, August 22, 2003 2:42 PM To: [EMAIL PROTECTED] Subject: Re: CGI/SSL spec? Thanks, but I was more so looking to find out if there was some sort of formal spec that the mod_ssl team used to decide what SSL environment variables to create. I am making some changes to stunnel to support http proxying and I wanted to include some headers for user CGIs. Since I can not find any spec, describing what SSL environment variables are expected, I have simply chosen to insert the headers X-Https and X-Session-Id. Thus spake Colin Faber, on the year of our L*rd Wed, Aug 20, 2003 at 05:32:58PM -0600: Dumping the environment variables is a very simple task. Try: #!/bin/sh echo Content-type: text/plain echo /usr/bin/printenv chmod it and stick it on your SSL server and run it. Philip Champon wrote: Hi, I tried searching the archives, to find out where I might be able to read about a CGI/SSL spec, but I couldn't turn anything up? While I have read the mod_ssl ref on envirionment variables, I was hoping to find out what source the group used to compile this list of environment variables. I also consulted the CGI spec, but it did not cover any SSL specific variables. Could someone tell me, is there such a spec, or did the group arbitrarily compile a list of SSL env vars to include in the CGI env? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] -- Philip Champon Affinity Developer Ph - 954-334-8156 Em - [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:
Ian, http://www.google.com/search?num=20hl=enlr=lang_enie=UTF- 8safe=offq=SSL+%22name+based+virtual+hosts%22spell=1 That's a Google query for: SSL name based virtual hosts The very first hit is: http://httpd.apache.org/docs/vhosts/name-based.html The summary text presented by Google reads: Name-based Virtual Hosts ... Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol. ... Using Name-based Virtual Hosts. ... If you don't like that one, there are 1,890 other matches .. several of the first 20 clearly say in the summary text presented by Google that you can't do name-based virtual hosts with SSL. Please note I have not to date, nor am I now, calling you [insert derogatory/deriding term or phrase here], nor am I saying you're a worthless human. I'm simply pointing out the obvious fact that the way your mind seems to go about solving problems and researching does not mesh well with the tasks you're trying to accomplish. You claim to have spent two MONTHS trying to find what I found in under 10 SECONDS. That doesn't make me one bit of a better person than you... it just says that my mind works in a way that is different from yours. I'd wager there are certain tasks you accomplish quite easily that would take me some effort. It's the way us humans seem to be designed. Every once in awhile, it's a good thing to look at who we are and what we're good at and then review what we've chosen to do in life. Doing a job that meshes well with how you think can be all the difference between looking forward to an rewarding day at the office and a bruised forehead from repeatedly smashing your head against a wall in self-frustration. [ of course, I'm omitting the forehead bruising caused by external influences like PHBs ;-) ] As for the tone of your note .. life's tough, grab a helmet. Kind Regards, -dsp On Thursday, Aug 21, 2003, at 00:05 US/Eastern, Ian Newlands wrote: If I hadn't already exhausted resources I would not have made this post in the first place. I have tried 3 different versions of apache, searched through previous postings, used search engines etc. bought 2 books on apache and have been attempting to get this going for almost 2 months now. I'm glad you're amused by my frustration here. If there is anyone out there that is willing to submit a serious response to this I would appreciate it greatly. Regards, Ian Newlands - Original Message - From: Dave Paris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Ian Newlands [EMAIL PROTECTED] Sent: Thursday, August 21, 2003 11:58 AM Subject: Re: virtual hosting geeze. is it that time of the month already for this question? seems like it was just yesterday when it was asked last .. maybe I'm just thinking of the other 100,000 times it was asked. in all seriousness, this dead horse has been beaten so many times on this list there isn't even a carcass left to hit at this point. please go dig through the mail list archives to see why name-based virtual hosts don't work with SSL. yes, that's a flippant answer. no, you're not likely to get a reply any more serious. -dsp On Wednesday, Aug 20, 2003, at 22:09 US/Eastern, Ian Newlands wrote: I am currently running about 15 virtual hosts using name based on port 80, and 1 virtual host using SSL. My SSL host is currently working with the following: VirtualHost _default_:443 However I want to change this to the IP based hosting for this host, allowing me to then add more SSL based virtual hosts on this setup, so I tried changing this to the following: VirtualHost 203.xxx.xxx.xxx:443 By doing this my SSL virtual host stops working altogether. I try the following to debug it on a remote machine: # openssl s_client -connect 203.xxx.xxx.xxx:443 CONNECTED(0003) 27604:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:475: I do the exact same thing on the local machine and it responds with a valid SSL response. Can anyone suggest might be wrong here? Regards, Ian Newlands _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL
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]
Re: configuration question
On Wednesday, Aug 20, 2003, at 00:32 US/Eastern, Arthur Chan wrote: Well, my eyes did glaze over somewhere betw thermodynamics and mobile perpetuum ;-) So does this mean that if I work in a less sophisticated infrastructure where only 56kbps ppp dialup is available, I can get some incremental gain by zipping it up before encrypting it ? [yes/no] Yes. ...And the larger the plaintext, the larger your gain, percentage-wise. (simply because larger plaintext files *tend* to shrink by a larger percentage when compressed) Caveats ? Both compression and encryption are computationally expensive operations. Don't skimp on the CPU for this machine. [] Best~ -dsp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: configuration question
I was not referring to post-encryption compression in the context of SSL or other, proven, known-sane encryption algorithms. I probably should have made this point *much* clearer to avoid confusion. I posed the scenario to would-be cryptographers who [99.9% of the time] wrongly believe they've created the next great encryption algorithm. In any case, the Apache processing chain applies SSL as the last stage anyway, so compressing *after* encryption, under normal Apache request processing, won't happen without someone [who knows *exactly* what they're doing] forcing the issue. Best~ -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eric Rescorla Sent: Wednesday, August 20, 2003 11:44 AM To: [EMAIL PROTECTED] Subject: Re: configuration question Cliff Woolley [EMAIL PROTECTED] writes: On Tue, 19 Aug 2003, Eric Rescorla wrote: Dave Paris [EMAIL PROTECTED] writes: In addition to Owen's salient points about compression working efficiently on repetitive strings in plaintext/binary data (e.g. whitespace in a Word document) and not on random data (e.g. encrypted data), some encryption algorithms can actually be weakened by compressing the resulting data, giving a cryptanalyzer clues to the inner workings of the algorithm. No reasonable encryption algorithm will be weakened this way. I agree. I'm guessing what he meant is that some encryption algorithms are weakened if their /input/ is pre-compressed by some known algorithm. If the cleartext is in some known format, it might possibly be easier to recover it from the ciphertext. True. But no modern algorithm is susceptible to this kind of known plaintext attack either. Moreover, SSL incorporates all sorts of opportunities for known plaintext. I wouldn't worry about this one. -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: virtual hosting
geeze. is it that time of the month already for this question? seems like it was just yesterday when it was asked last .. maybe I'm just thinking of the other 100,000 times it was asked. in all seriousness, this dead horse has been beaten so many times on this list there isn't even a carcass left to hit at this point. please go dig through the mail list archives to see why name-based virtual hosts don't work with SSL. yes, that's a flippant answer. no, you're not likely to get a reply any more serious. -dsp On Wednesday, Aug 20, 2003, at 22:09 US/Eastern, Ian Newlands wrote: I am currently running about 15 virtual hosts using name based on port 80, and 1 virtual host using SSL. My SSL host is currently working with the following: VirtualHost _default_:443 However I want to change this to the IP based hosting for this host, allowing me to then add more SSL based virtual hosts on this setup, so I tried changing this to the following: VirtualHost 203.xxx.xxx.xxx:443 By doing this my SSL virtual host stops working altogether. I try the following to debug it on a remote machine: # openssl s_client -connect 203.xxx.xxx.xxx:443 CONNECTED(0003) 27604:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:475: I do the exact same thing on the local machine and it responds with a valid SSL response. Can anyone suggest might be wrong here? Regards, Ian Newlands _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: configuration question
In addition to Owen's salient points about compression working efficiently on repetitive strings in plaintext/binary data (e.g. whitespace in a Word document) and not on random data (e.g. encrypted data), some encryption algorithms can actually be weakened by compressing the resulting data, giving a cryptanalyzer clues to the inner workings of the algorithm. The bottom line here is that SSL works on the socket/transport layer and not at the application layer. If you're generating a .gz file on-the-fly within Apache (mod_gzip, etc), the result will still be encrypted *after* compression. The output chain of Apache applies SSL as the last stage, so something like mod_gzip will operate *before* SSL. Most modern browsers produced in the last four or five years will decompress a .gz file (not .zip!) for the user - even on Windows (just tested IE6 on XP .. works fine). If you've ever experimented with VRML, one best practices is to send files as .wrl.gz and not straight .wrl. As for SSL packets being larger - they're not to any appreciable degree - for the exact reason Owen pointed out below. Even symmetric cipher algorithms don't produce appreciably larger amounts of data. For example, using Chained Block Cipher (CBC) mode will only increase the amount of data by 8 bytes from adding an Initialization Vector (IV) to the beginning of the ciphertext and padding the end of the ciphertext to get a complete final block (with an 8 byte block cipher like Blowfish, the largest amount of padding will only be 7 bytes). So, at most, you've added 15 bytes to even the largest amount of plaintext data using Blowfish in CBC mode. There are a few exotic exceptions here, like interleaved chaining block ciphers which will add an IV (of the same size as above) per parallel operation (so if you've got four parallel encryption operations using interleaved CBC, you're adding 24 bytes at the beginning of the ciphertext). However, these are exceptionally rare and typically limited to proprietary implementations/applications. Addressing one other misconception here.. a packet can contain up to 1500 bytes - including headers (assuming your network handles MTUs of 1500, some are less (like ATM @ 53 bytes [48 bytes of payload w/5 bytes of header), some are more (like Frame Relay @ up to 4500 bytes), but hey, not many desktops are connected with ATM or Frame, so we'll call the connection standard ethernet with a MTU of 1500. The way networks operate and packets are forwarded, smaller packets actually transmit *less* data for any given amount of time over larger packets. Switches and routers (OSI layer 2 and 3 devices) operate on packet forwarding rates, regardless of the amount of data in the packet. The more data in the packet, the more data you're going to get for X period of time - this is one factor that introduces latency into a network. Lots of small packets going through a network simply transmit less data than lots of large packets .. and since the only appreciable metric is the number of packets and the packet forwarding rate of the network device, the larger the packet, the happier the network and the more data getting to the end user. The *only* place this is going to make a difference is if you've got an -inline- intrusion detection/prevension system (IDS/IPS), in which case you've got what most network engineers would consider to be a design flaw anyway. In this case, each packet needs to be inspected and the more data there is, the more there is to be inspected. Most IDS sensors will simply discard packets being inspected rather than slow the network down (Snort does this when it's either misconfigured or overloaded). So.. go for it. Use mod_gzip (or similar) to generate .gz docs on the fly .. let Apache handle your SSL. If anything, your win comes from SSL having to encrypt *less* data. This won't speed up the handshake phase, but will speed up the rest of the transaction since there's simply less data to encrypt and transmit. How much speed improvement you get is completely 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
RE: CRL updating with mod_ssl
Your actual message issue notwithstanding, the versions you're running are not just old, they've got security flaws and vulnerabilities well documented at both CERT, apache.org, and openssl.org. http://www.cert.org/advisories/CA-2002-27.html (Linux, Apache, OpenSSL, mod_ssl) http://www.cert.org/advisories/CA-2002-23.html (OpenSSL) http://www.cert.org/advisories/CA-2002-17.html (Apache) If you've got support preventing *you* from upgrading, *DEMAND* they be updated to reduce your security risks, vulnerability, and liability. If your support contract won't do that, you don't have support and you should upgrade to current anyway. Respectfully, -dsp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roberto Hoyle Sent: Tuesday, August 19, 2003 1:56 PM To: [EMAIL PROTECTED] Subject: CRL updating with mod_ssl I'm trying to understand when a CRL list gets read by Apache. I have cases of it being read when a new CRL is placed in the directory and the make is run, and cases when it does not get read under identical circumstances. The only reliable way that I have to make sure that the CRL gets updated is by restarting the server. Is this supposed to be the case? I'm confused that it works sometimes and doesn't work on others. Right now, I'm running 1.3.19 with mod_ssl 2.8.1 (yes, I know that they are old, but I am not able to update them for support reasons...). We have the SSLCARevocationPath directive set to the proper location, and a script that downloads a new CRL every evening and runs the make. The script does not kick the server. Our CRLs expire in seven days, but get published every evening. Should I just stop worrying and learn to love restarting Apache? Thanks, r. -- Roberto Hoyle PKI Lab Programmer Dartmouth College __ 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
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
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]
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]
Re: how to add multiple SSL cert for each virtual host?
Look at the handshake for SSL. During the name to address translation phase, you wind up with a chicken-egg scenario if more than one name shares an address. Not only is it not possible, it'd be a HUGE security flaw if it WERE possible. -dsp On Tuesday, Dec 3, 2002, at 15:34 US/Eastern, Hack Hawk wrote: What?!?!?! Are you absolutely sure about this? SSL certs are based on the Domain Name,,, NOT the IP address. It stands to reason that it would be possible for virtual hosts/domains to have their own certs. Perhaps modssl doesn't support it, but I think that in theory it's possible. - hawk At 10:24 AM 12/03/2002, you wrote: Multiple SSL certs for name-based virtual hosts aren't possible based upon the way SSL is designed. Each site requiring a separate cert must have it's own IP address. --- Shawn Syms | Systems Administrator Infinet Communications | [EMAIL PROTECTED] --- -Original Message- From: Thomas Sandor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 1:20 PM To: [EMAIL PROTECTED] Subject: how to add multiple SSL cert for each virtual host? hi everyone, I have an apache 2.0.40 installed on a RedHat 7.2 box, complied with ssl (openssl 0.9.6g). Till now I had only one domain for which apache should use SSL cert files (crt, key), but for our next project I have to add another SSL cert file a specific domain. I have NameVirtualHost 12.34.56.78 and have a list of virtualhost/ for each of our domain, using ServerNamed base aliases, but for the ssl conf it ain't works. In my ssl.conf in short looks like this: NameVirtualHost 12.34.56.78:443 VirtualHost 12.34.56.78:443 ServerName domain1.com CustomLog ... ErrorLog ... SSLEngine on SSLCertificateFile /somewhere/ssl.crt/domain1.crt SSLCertificateKeyFile somewhere/ssl.key/domain1.key /VirtualHost VirtualHost 12.34.56.78:443 ServerName domain2.com CustomLog ... ErrorLog ... SSLEngine on SSLCertificateFile /somewhere/ssl.crt/domain2.crt SSLCertificateKeyFile somewhere/ssl.key/domain2.key /VirtualHost The problem is that apache does not serve domain2 cert files for domain2, it uses the first declaration for every https://domainX.com invoke. Does anyone know how to tell apache to uses specific SSL cert I'd like to define for each of my virtualhosts? Thanks in advance for any help. Regards, Thomas __ 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: mod-ssl Virtual Hosts
a) you could try surfing the archives of this list since an arguable 10% of the traffic is either this exact question or directly relates to it. b) you could use different ports c) you could use different IPs. they're not *that* rare .. and .. it could be sanely argued that if you've got content important enough to protect using SSL, the cost of using up an IP is just part of the cost of making that _important_ information accessible. -dsp On Friday, Nov 8, 2002, at 18:30 Europe/London, Irving Carrion wrote: Hello All! Just recently I was able to get this mod-ssl library working on Apache. It is working just fine. Much thanks to the developer team. Anyway my question is... Currently I use name-based virtual hosts for all of our websites. http://domain1.com http://domain2.com We would like to have the ability to get each domain a https address as well like... https://domain1.com https://domain2.com What would be the best method of tackling this, since mod-ssl doesn't support name-based virtual host? I've thought of using IP Based virtual host, but there isn't enough static ip's to go around. I've also thought of using proxypass/proxyreverse to point it to an internal static ip. Am I on target with this? I would really appreciate any help or suggestions ANYONE can provide. Thanks! IRV __ 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: Single IP and need two virtual SSL servers
http:// is *NOT* the same thing has https:// .. therefore, http://host:443 is a standard HTTP request to port 443, it is *NOT* a HTTPS request. URL 101 is in session! protocol://user:pass@host:port/uri and since http is not the same thing as https, the server is simply giving you back precisely what you asked for .. non-secure http from port 443 .. which it doesn't know how to do since it's only designed to speak secure http. no wonder you found IIS5 to be better than in the past .. Microsoft doesn't understand what RFCs are either. ::sigh:: -dsp [EMAIL PROTECTED] wrote: Hi guys! I am Apache webserver user too. I don't know how long... IIS5 is much better now than in the past. I had have this problem in the past using Apache. As far as I know, seems that apache use distinct IPs for every virtual SSL host configured. So I see no solution for you unless if you could build a second SSL virtual server using other port than default port 443. Suppose that will work how will access browsers your website using encryption? Browsers know to communicate encrypted using https protocol witch is default set on 443 port. Why am I saying that? I made few tests: 1. http://www.inetsoft.ro:443 who generated these: Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://www.inetsoft.ro:443/ 2. https://www.inetsoft.ro who worked! 3. I changed 443 port in 444 for one of my websites http://xxx.aaa.ro. https://xxx.aaa.ro/ was redirected by apache to default SSL virtual host. Conclusion: I don't know! :) [...] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: few questions
David Loszewski wrote: I have a few small questions that I'm seeking answers for, any help would be much appreciated: 1. Mod_SSL is working...I type in 'https://192.168.0.1' and it uses the ssl but when I type in 'http://192.168.0.1:443' it doesn't work, comes up saying that it can't load the page. Ideas? URLs are encoded by protocol first. HTTP is *not* HTTPS. Plain and simple. Your suggestion might as well by wondering why http://127.0.0.1:21 doesn't make your web client a FTP client. Most web browsers *can* do FTP, provided you type ftp://... 2. How do I make it so if I type in 'http://192.168.0.1' it goes to 'https://192.168.0.1', pretty much so it only uses ssl, and please don't tell me to just redirect it. You'll need to redirect it somehow, someway. The client is requesting one protocol and you want them to request another. If *you* don't redirect it, then .. uhmm .. who are you expecting will? Santa Claus is busy routing presents, not packets. Look into mod_rewrite. 3. This is more of a curious type question, but if https is so much more secured than http then why aren't all the big sites using it? so much more secured .. one uses encryption, one doesn't. HTTP isn't secure at all. As for why not.. becuase buying racks full of majorly expensive SSL accelerators to hide information you want shown to as many people as possible is $#!*ing dumb. -d __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Firewall shows 80 in/out, Apache shows nothing
Dave, Unfortunately, those firewall logs are all but worthless as they don't detail what type of packet is being sent and what the reply is, nor the source port for the reply. Trying to ascertain what's going on here without real packet data is akin to looking at railroad tracks and wondering which way the train went. --dsp Deocs Postmaster wrote: On Mon, 11 Jun 2001, Deocs Postmaster wrote: The following is from my firewall log file: Incoming: 06/11/2001 19:19:59 200.4.193.240[3268] == 192.168.1.100[80] 06/11/2001 19:19:59 200.4.193.240[3268] == 192.168.1.100[80] 06/11/2001 19:20:00 200.4.193.240[3268] == 192.168.1.100[80] 06/11/2001 19:20:00 200.4.193.240[3268] == 192.168.1.100[80] Outgoing: 06/11/2001 19:19:59 192.168.1.100 == 200.4.193.240[3268] My Apache logs don't show any traffic for 200.4.193.240, but does show the other hit-by-hit traffic. This particular hit was from Peru. I recall seeing the same thing from China earlier. How did it go in and out, but not show up in any Apache log files? Well, this has nothing to do with mod_ssl, but to answer your question, this would happen anytime somebody connects to your server and disconnects before making an actual HTTP request. Maybe they STARTED to make one and disconnected mid-request. Thanks for the reply, I may have been ambiguous in my email. The incoming firewall shows four hits and the outgoing shows one reply. None of the Apache log files show any traffic to or from 200.4.193.240. Would the outgoing traffic be present if they disconnected mid-request? My security concern is that it appears that some message was sent to port 80 on the server, and that computer appears to have replied, but I can't see in the log files that Apache was the program that replied. So what program on the server sent the outgoing message? Thanks, Dave (I sent a similar reply earlier, but it hasn't surfaced yet) __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0
[..snip a bunch of sane pondering at completely inexplicable behavior by third parties..] The only thing I currently know is that with Apache 2.0 it seems that we again will have the same SSL/TLS problem as we had three years ago with Apache 1.3 (means: an unpolished 70% percent solution). And I also know that someone (not necessarily me) will again find this not satisfactory. What approach then is used to change this we all still don't know... Ralf, take heart that you're not alone here. As much as I believe in and work for OpenSource projects, this is the achilies heel of them all. They completely forget they are still developing applications for a USER BASE. When their internal politics flies in the face of what's best for that user base, the project comes off looking like it was done by a gaggle of immature, clue-challenged fruckwits who cannot grasp the basics of how to run a successful project. mutters something about forgetting and repeating history... Apache has been (arguably) one of the best OS projects to date. It pains me to see the obvious, and most successful current SSL implementation not be chosen for the 2.0 revision. I definitely don't recall seeing a user-community vote on the topic of SSL/TLS choice for the 2.0 revision. I'm sure there are many folks who would have appreciated the opportunity to have voiced their opinion. Heck, even large companies like Computer Associates take polls of that nature. After all, if the project doesn't do its best to increasingly serve the user base that's grown along with it, what's the point? Surely the point can't be politics - that's reserved for those extra-special folks who speak far more and work far less. just my $0.02 at the state of some recent, mind-bogglingly stupid moves in the OpenSource community. --dsp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Why pay a CA?
While I can appreciate the "why do we have to pay these mooks?!" attitude, the reasoning is rather more straightforward. It seems those making the silly** (imho) arguments have forgotten the entire reason for a "trusted third party" (in this case, the CA). User U heads over to site S and wishes to conduct a transaction, except U has never dealt with S, nor does U have the time to do background checks on S to significantly reduce the risk that S may actually be a fraudulent front end for a questionable organization. Note that I'm not saying this completely mitigates the risk, as it certainly does not. However it does go quite some ways to reducing the risk. This same notion is at the heart of many types of cryptographic protocols and key escrow (ick) systems. I do completely agree that much over $50 for a certificate is a bit bonkers (please, someone tell me that 90% of the process isn't completely automated .. I really need to laugh). However, until a majority of cert purchasers really understand *how* and *what* trusted third parties work, the current price is liable to be with us. regards, --dsp Notes: ** James "I'm not a cynic" Moore's line: "A cynic might argue that CAs represent the sleaziest sort of pandering; that it is designed to exploit the ignorance of the average consumer..." [ok, so what do you think would happen to a large, publicly traded company if they failed to maintain their position as a trusted third party? Can you say "class action lawsuits for very big $$$"? (along with a few other minor ditties)] ** Lanny "we'll show 'em!" Baron's eloquent rambling: "Well the one reason we don't use a CA that m$ wants or netscape wants, is to show potential purchasers of our systems that the system is quite capable of running https as well as Apache for web hosting or for Intranet and Extranet." [great business plan, way to win the confidence of a potential client. "please give us your money *and* we'll shove our viewpoint down your throat." sign me right up, I'll take two to go.] ..and.. "The problem remains that, people unfamiliar with Unix or CA's or Mod-SSL would most likely be scared to input their credit cards or other personal/financial data." [whatever you're smoking, please share so the rest of us enjoy as well. That sentence registers in negative integers on the makes_senseometer. How many Amazon.com users care if that site runs off Unix or a banana running Apache, IIS, or a tricycle for a HTTPd? They don't care, they shouldn't need to care, and they have no problems parting with $$$ (now, as for Amazon turning a profit .. well, that's not the user's problem :)] On 6 Dec 2000, Owen Boyle wrote: Michael wrote: Is there any reason to pay for Verisigned keys or does setting up our companies own CA work equally well? Technically, a self-signed certificate will work perfectly well. However, the browser will "inform" the user that it doesn't recognise the authority that signed this certificate. If you use Verisign etc.. the browser will already recognise them as a Certificate Authority and accept the certificate without a squeak. It depends what you want to use SSL for. If you want strangers to send you their private details, you'd be better off with a commercial certificate since they won't be frightened by the "warnings". However, if you are using SSL for a specific closed group of users, then use your own certificate and inform them about it... __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Why pay a CA?
If an eight-year-old were to look at the whole thing and write your reply, then yes .. what you've written would probably be accurate - just missing other fun phrases like "dooty-head", "cooties", etc. DB aren't a bunch of rank amateurs when it comes to checking the legitmacy of a business. As for "who decided that X was really trustable", it was people who are a) most likely on the net wayyy before you. (pre-web) a) probably more knowledgable than you (have you tried out-marketing MS recently?[1]), b) definitely uninterested in asking you, c) backed with more corporate $$$ than you, more-than-likely and d) well, you're stuck with it. they're doing a passable job and you can't change it anyway. (despite all the whining I've heard about verisign, I've yet to experience even one delay in getting a cert using their online toolset - however I won't discount these other stories, so verisign gets nothing above "passable") You can either dance with an elephant or get run over by him. Your choice, choose wisely. Yes, I hate it that VeriSign bought Thawte. It sucks. It ruins competition. I've dealt with both and I preferred Thawte, despite their *massive* client cert expiration fustercluck with IE two years ago. Oh well, the bus is leaving the station and I still have to get on to another town. If you're walking, I'll see you there after awhile. regards, --dsp NOTES [1] I don't purchase their software, I don't like their tactics, and I'll subvert them any chance I get, but you'll *never*, *ever* see anyone with two brain cells try to out-market them, including me. They've got metric f**ktons of $$$ and have an utter mastery of marketing tactics. You go around something like that, not head-to-head. Michael wrote: So the main protection is that company x charges a fee large enough to company y in order to prove company y is a real company and not highschool students trying to rip off users. of course there is no proof that being able to afford a certificate really makes you anymore qualified than small business z and who decided company x was really trustable. all xompany x has proven is that they grasp the concept of this security model well enough to pretty much blackmail company x, company z, etc into paying out the arse for their 30 seconds of work. Maybe is a bit cynical but is that the gist of how it works? *^*^*^* Have the courage to take your own thoughts seriously, for they will shape you. -- Albert Einstein On Wed, 6 Dec 2000, Dave Paris wrote: While I can appreciate the "why do we have to pay these mooks?!" attitude, the reasoning is rather more straightforward. It seems those making the silly** (imho) arguments have forgotten the entire reason for a "trusted third party" (in this case, the CA). User U heads over to site S and wishes to conduct a transaction, except U has never dealt with S, nor does U have the time to do background checks on S to significantly reduce the risk that S may actually be a fraudulent front end for a questionable organization. Note that I'm not saying this completely mitigates the risk, as it certainly does not. However it does go quite some ways to reducing the risk. This same notion is at the heart of many types of cryptographic protocols and key escrow (ick) systems. I do completely agree that much over $50 for a certificate is a bit bonkers (please, someone tell me that 90% of the process isn't completely automated .. I really need to laugh). However, until a majority of cert purchasers really understand *how* and *what* trusted third parties work, the current price is liable to be with us. [...] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Permanent re-direct
Before blindly screaming "It's broken!", think about *why* you need suexec first. If you aren't going to use it, then don't bother enabling it. I run configurations with a heavily modified (for values, not for additional defines or typedefs) apache_[ver]/src/include/httpd.h. These typically have SUEXEC_BIN linked to /dev/null as well as SHELL_PATH. The reasoning is pretty obvious; if I'm not going to use it, why should I leave even a remotely possible attack point in the server if I lose my mind and do Something Stupid [tm]? Apache allows for large amounts of tweaking. There are some things which are prudent to disable if you're not going to use them. (where "disable" means: "no, you *can't* change this behaviour without rebuilding the executable"). The bulk of the folks out there will *not* get suexec calls right, which, more often than not, will put a nice, big security hole in the box. I don't point SHELL_PATH to anything but /dev/null since I don't use anything but mod_perl environments. YMMV. Be alert, the world needs more lerts. --dsp "Robert L. Yelvington" wrote: regarding 'suexec'.. you must have misconfigured suEXEC when you compiled...where is your suexec log file .AND. what does it say .OR. what other useful suexec log information can you forward to the list? your configure flags would also be helpful... thanx, rob John Markunas wrote: Hi I do a httpd -l and get compiled in modules http_core.c mod_so.c suexec: disabled;invalid wrapper /usr/sbin/suexec Can someone tell me why I get the suexec error and what to do to fix it ?* __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Build problem: sanity check fails and cannot open -lgdbm
[EMAIL PROTECTED] wrote: /usr/bin/ld: cannot open -lgdbm: No such file or ... [snip] + SSL interface plugin: Vendor DBM (libndbm) [snip] --enable-rule=SSL_SDBM it could be as simple as you don't have gdbm in your path, or you don't have it installed. www.sleepycat.com has a dbm package that might fix your problem. From their FAQ : Is Berkeley DB 2.X backward compatible with: Berkeley DB 1.85? Dbm/Ndbm(3)? Hsearch(3)? The Berkeley DB 2.X library provides backward compatible interfaces for the historic UNIX dbm(3), ndbm(3) and hsearch(3) interfaces. See the Berkeley DB manual pages for more information. If you're receiving this error on a Linux (RedHat) system, you can also head over to 'www.rpmfind.net' and get the gdbm-devel RPM .. which nicely makes this error go away. :-) -dsp __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [BugDB] PRIVATE: Setting up Apache Server with mod_ssl (PR#199)
May I politely point out that Win2K is _BETA_. If something's b0rken, go back to a known, stable platform. -dsp -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, July 01, 1999 12:32 PM Subject: [BugDB] PRIVATE: Setting up Apache Server with mod_ssl (PR#199) Full_Name: Kai Ming Chan Version: 2.3.5 OS: Windows 2000 Submission from: proxy2.ch.intel.com (143.182.246.21) I followed the steps in install.win32 and was able to build openssl and apache. However, I don't know how to do step 6. "6. Now you're on your own, because Win32 is not an officially supported platform of mod_ssl. You have to setup the config files and certificates manually. Good luck..." I know win32 is not supported, but could you just give me some hints of setting mod_ssl up with apache. What do I need to change in the cofig file? How do I make the certificate and where do I put it? Thanks! Ming __ 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: giving up.
nreese wrote: Tried for 2 weeks to get mod_ssl to work. Im giving up. Im going over to the dark side and using Commercial Ware. Hopefully someday GNU software will function. Hrmm.. you mean like gcc, bison, flex, autoconf, automake, et al.? GNU software functions just fine, thankyouverymuch. (and it works even better when people contribute patches or documentation rather than simply whining "It Doesn't Work!") With so many people using GNU software (including mod_ssl and OpenSSL) successfully, it seems to me to be quite short sighted (and ill-informed/under-educated) for you to make such a posting with a statment as included in your original above. Live long and pay large sums of money... -- Regards, Dave P: [EMAIL PROTECTED] W: [EMAIL PROTECTED] "Why is the machine faster?" "We lubricated the sticky bits, it's much smoother now." __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Child pid exit signal Segmentation fault (11)
"Ralf S. Engelschall" wrote: [...] Is this SuSE Linux where such problems occured because of the vendor NDBM library? This is also a problem on RedHat 6.0. Here's the longterm fix I used... ## notice this is a cp and *not* a mv!! cp /usr/include/db1/ndbm.h /usr/include/ndbm.h and apply the following patch: ### start patch ### --- /usr/include/ndbm.h Fri Apr 16 18:48:25 1999 +++ /usr/include/ndbm.h Thu May 20 17:13:41 1999 @@ -39,7 +39,7 @@ #ifndef _NDBM_H #define_NDBM_H 1 -#include db.h +#include db1/db.h /* Map dbm interface onto db(3). */ #define DBM_RDONLY O_RDONLY @@ -77,3 +77,11 @@ __END_DECLS #endif /* ndbm.h */ + + + + + + + + ### end patch ### At that point, everything and anything requiring the 'normal' placement of ndbm.h still finds the correct db.h (there are two on glibc2.1 .. one in /usr/include and another in /usr/include/db1 .. they are *not* the same file. Happy patching .. and I'll probably whip up a quickie tool to automate this (if you'd like, Ralf, I can send it to you for inclusion as need) -- Regards, Dave P: [EMAIL PROTECTED] W: [EMAIL PROTECTED] Ubergeek - AnglersWeb, Inc / W3Works, LLC Data Monger - Gestalt Technology, LLC "Why is the machine faster?" "We lubricated the sticky bits, it's much smoother now." __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: ModSSL Breaks Apache
nreese wrote: Im having a lot of problems. First the RSAref library that openssl tells me to use doesnt exist, rsa is not giving it out anymore. As I recently pointed out, stick "http://ftpsearch.lycos.com" into a browser and search for: rsaref20.tar.Z .. there are a plethora of sites holding valid archive images. Then OpenSSL compiles fine. Mod_SSL compiles fine. I am following the instructions given in the mod_ssl tarball. Anyway when I get down to compiling Apache I see this, after lots of other standard compiler output. === src/modules/standard === src/modules/ssl gcc -c -I../../os/unix -I../../include -DLINUX=2 -DMOD_SSL=202108 -DUSE_HSREG EX -DEAPI `../../apaci` -DSSL_COMPAT -I/root/openssl-0.9.2b/include -DMOD_SSL_VE RSION=\"2.2.8\" mod_ssl.c In file included from mod_ssl.c:65: mod_ssl.h:282: ndbm.h: No such file or directory make[4]: *** [mod_ssl.o] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/root/apache_1.3.6/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/root/apache_1.3.6' make: *** [build] Error 2 [root@www apache_1.3.6]# -- This is quite distressing. I notice that in the INSTALL doc there is mention of ndbm (whatever that is) and that it should be "included by my vendor". Anybody know how to fix this? Not without you providing more details on your platform (although I'm very willing to guess you're talking about RedHat 6.0) .. see my post from last week for a complete build list to generate this package on RH6.0. -- Regards, Dave P: [EMAIL PROTECTED] W: [EMAIL PROTECTED] Ubergeek - AnglersWeb, Inc / W3Works, LLC Data Monger - Gestalt Technology, LLC "Why is the machine faster?" "We lubricated the sticky bits, it's much smoother now." __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: Will this kill this project? http://www.newsbytes.com/pubNews/122463.html
The biggest thing to remember in amidst all this legal light show crap is that the longer these countries hold down strong encryption, the longer they hold back widespread Net commerce... commerce that adds jobs, increases the taxable income of companies and, in the long term, increases the government's income from both corporate and personal taxes. All of which comes right around again to fight terrorists and all the people they're worried about using the strong encryption. The bottom line: strong encryption is no different that any other weapon - if it's illegal, then only criminals will have it (exactly the opposite of what the law tries to prevent). In this case, keeping it illegal also stunts the growth of the world economy at the same time. So, when you take away all the rhetoric and utterly inane arguments, keeping strong encryption bottled is really a very silly thing to do. Regards, dsp [EMAIL PROTECTED] -+-|-+- [EMAIL PROTECTED] #include disclaimer.h What's a nose for? It's for aerodynamics, like running. Get it? Nose .. running? -- my wife On Saturday, December 05, 1998 4:23 AM, Ralf S. Engelschall [SMTP:[EMAIL PROTECTED]] wrote: On Fri, Dec 04, 1998, William X. Walsh wrote: What impact will this have on the mod_ssl project if it is indeed accurate? http://www.newsbytes.com/pubNews/122463.html A few facts from my point of view: 1. Although the article said "Germany is among the countries that agreed to make their controls more strict at the Wassenaar meeting" AFAIK this is still only a press information IMHO. Nothing really happended until now AFAIK. And because since a few weeks we've a new government I'm not convinced that this will really happen. At least the new government is less conservative than the old, so such crypto laws have less chance. 2. mod_ssl is distributed from _Switzerland_ and not from Germany, because www.engelschall.com is located in Zurich, Switzerland at the ETHZ. So even when our German law should change we can distribute/export mod_ssl from there unless I've do my development on this machine, too. 3. Really good pieces of software never get lost: there is always one who takes it over and develops it further for the community. So even when I personally would no longer be allowed to develop mod_ssl I'm sure we find someone who can take it over. At least I currently try hard to make mod_ssl the cleanest SSL solution for Apache, so I'm convinced that a new developer can be found when all should go finally bad with the laws. So, don't panic. I'm sure mod_ssl will survive those law issues... Greetings, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Any confirmation yet?
Have we received any "in print" confirmation from RSA with regards to us using one license from a commercial package to build and use mod_ssl in the States? Regards, dsp [EMAIL PROTECTED] -+-|-+- [EMAIL PROTECTED] #include disclaimer.h The two most oft overlooked motor vehicle laws: Inertia and Tonnage __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: rsa
Just a pondering here, but in the -spirit- of the law (and probably not the letter), and given the fact that I'm not a lawyer, what if we (US developers) were to purchase a commercial solution, shelve it, then use that license in our own (individual) mod_ssl package? We still have only one RSA implimentation running, and we have a single RSA license. That way, RSA has their licensing fees. Logically, that make sense to me, but US law only makes sense on rare occasions. dsp On Friday, November 20, 1998 1:16 AM, Preston Brown [SMTP:[EMAIL PROTECTED]] wrote: Basically, RSA has discontinued all support for their rsaref stuff, and they wish it would just go away. At least, this is how they are making it appear to the outside world. To really use RSA encryption in the US, you have to go with a third party solution, such as Red Hat Secure Web Server, Roxen, Stronghold, Raven, etc. etc. etc. --- -Preston Brown Red Hat Software, Inc. [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
