Re: Mod-ssl and apache configuration question
On Fri, Nov 05, 2004 at 05:07:06PM -0700, Kory Wheatley wrote: I have a project where I need to setup an Apache secure server. I have an Apache non secure server already on my workstation. I don't want the Apache secure server to run under the same daemon service, so I've downloaded a separate Apache tar file. This server also needs to run under a different user and group. What is the steps of compiling Mod_SSL and DSO into Apache and under a different server user. This setup will only be for a secure server and no other virtual hosts. If there's a step by step process to do this that would be really nice. You don't need anything special to do this - just build apache with mod_ssl and change the config so that you have it listening on port 443 only. Then change User and Group to whatever user you want it to run under. That's really all you need to do. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Mod-ssl and apache configuration question
I have a project where I need to setup an Apache secure server. I have an Apache non secure server already on my workstation. I don't want the Apache secure server to run under the same daemon service, so I've downloaded a separate Apache tar file. This server also needs to run under a different user and group. What is the steps of compiling Mod_SSL and DSO into Apache and under a different server user. This setup will only be for a secure server and no other virtual hosts. If there's a step by step process to do this that would be really nice. -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 # Everything must point to him. __ 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
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]
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]
configuration question
Hi I have a web app which serves both static and non static content, both secure and unsecure(https and http). Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. But, I don't want to generate absolute URLs on the fly to link to non-secure static content. What I want is to make request to certain urls less secure such that processing is faster. For example, I have a directory called art, which is just a defined alias for a directory. Is there a way to make ssl processing for this directory less restrictive than for the generic requests to the virtual host so that processing is faster? Home someone can help Henrik Bentel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: configuration question
On Wed, 20 Aug 2003, Henrik Bentel wrote: Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. If I understand your question correctly, what you're wanting is to have some web page that's served up with https, but to have the images on that page be served by regular http. You could do that, but every browser I know of will throw a security warning in that case. You can't mix secure and non-secure content in the same document. Does that answer your question? --Cliff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: configuration question
-Original Message- From: Henrik Bentel [mailto:[EMAIL PROTECTED] I have a web app which serves both static and non static content, both secure and unsecure(https and http). Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. To add to Cliff's comment about browsers complaining about the mix of secure an insecure content there is a genuine security reason for *not* doing what you propose. Put yourself in the position of a crook who has gained access to the datastream flowing into your SSL server. As you are probably aware, all encryption ciphers can be cracked by a brute force attack (making repeated attempts at guesssing the key). Hopefully, the time-to-crack will be long, but you don't know how fast the crook's computer is. If he works for the NSA, it might be very fast indeed. If you serve all content via SSL, he has no idea which packets are important and which are just images etc. so he has to crack everything. If you decide to save a teeny bit of processing on the server by encrypting only the important things, he then sees lots of en clair packets (containing image data etc.) which he can safely ignore and only a few occasional nuggets of encrypted data which he can be sure are worth cracking. Thus he can focus his efforts on these. Therefore, you make life easy for the cracker by highlighting the packets that are worth cracking! In other words, the best place to hide a leaf is in the forest. You shouldn't need to worry about the processing load of the SSL encryption. If it is slowing your server, then, frankly, your server is not powerful enough to serve the traffic you have - get more memory, upgrade the chipset, do whatever is necessary to get up to speed. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. But, I don't want to generate absolute URLs on the fly to link to non-secure static content. What I want is to make request to certain urls less secure such that processing is faster. For example, I have a directory called art, which is just a defined alias for a directory. Is there a way to make ssl processing for this directory less restrictive than for the generic requests to the virtual host so that processing is faster? Home someone can help Henrik Bentel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Swiss Exchange. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Swiss Exchange. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière de la SWX Swiss Exchange. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: configuration question
Hi Boyle, I've been debating with myself over whether to encrypt everything, that's a cogent argument you have offered. I have a few questions myself : (1) assuming an openssl encrypted packet is bigger than a plain text one, would mod_gzip shrink it significantly to warrant the effort? (2) and would that slow down the client browser display of content ? On the other hand, with these new 1GHz+ P4 desk- and lap-tops around, maybe not. - Original Message - From: Boyle Owen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 04:49 PM Subject: RE: configuration question -Original Message- From: Henrik Bentel [mailto:[EMAIL PROTECTED] I have a web app which serves both static and non static content, both secure and unsecure(https and http). Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. To add to Cliff's comment about browsers complaining about the mix of secure an insecure content there is a genuine security reason for *not* doing what you propose. Put yourself in the position of a crook who has gained access to the datastream flowing into your SSL server. As you are probably aware, all encryption ciphers can be cracked by a brute force attack (making repeated attempts at guesssing the key). Hopefully, the time-to-crack will be long, but you don't know how fast the crook's computer is. If he works for the NSA, it might be very fast indeed. If you serve all content via SSL, he has no idea which packets are important and which are just images etc. so he has to crack everything. If you decide to save a teeny bit of processing on the server by encrypting only the important things, he then sees lots of en clair packets (containing image data etc.) which he can safely ignore and only a few occasional nuggets of encrypted data which he can be sure are worth cracking. Thus he can focus his efforts on these. Therefore, you make life easy for the cracker by highlighting the packets that are worth cracking! In other words, the best place to hide a leaf is in the forest. You shouldn't need to worry about the processing load of the SSL encryption. If it is slowing your server, then, frankly, your server is not powerful enough to serve the traffic you have - get more memory, upgrade the chipset, do whatever is necessary to get up to speed. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. But, I don't want to generate absolute URLs on the fly to link to non-secure static content. What I want is to make request to certain urls less secure such that processing is faster. For example, I have a directory called art, which is just a defined alias for a directory. Is there a way to make ssl processing for this directory less restrictive than for the generic requests to the virtual host so that processing is faster? Home someone can help Henrik Bentel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Swiss Exchange. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Swiss Exchange. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière de la SWX Swiss Exchange. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl
RE: configuration question
-Original Message- From: Arthur Chan [mailto:[EMAIL PROTECTED] Hi Boyle, I've been debating with myself over whether to encrypt everything, that's a cogent argument you have offered. I have a few questions myself : (1) assuming an openssl encrypted packet is bigger than a plain text one, Why would you assume this? Essentially; encrypted_text = f(plain_text, key) where f() is a mathematical function. I guess the 2nd law of thermodynamics (entropy increases) would tend to cause the output to increase but not necessarily by much. In the simple case of a substitutional cipher, the encrypted text would be precisely the same size as the plain text. would mod_gzip shrink it significantly to warrant the effort? Zipping algorithms work by replacing repetitive sequences in the input with shorter instructions to regenerate them (e.g. 1000 blue pixels - 1 blue pixel x 1000). Compression works best with highly structured input data (bitmaps, WAV files, human language etc). With random data, it can't make much difference and will even cause the file to grow! (try repeatedly zipping a file to see this happening). (2) and would that slow down the client browser display of content ? Unzipping requires the client to have winzip - not a default on a windows client! Probably this would slow the whole thing down. Remember that SSL is well-defined on the web and all recent browsers contain fast and effective SSL software - I would trust it to do its job and not try to re-invent the wheel. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. On the other hand, with these new 1GHz+ P4 desk- and lap-tops around, maybe not. - Original Message - From: Boyle Owen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 04:49 PM Subject: RE: configuration question -Original Message- From: Henrik Bentel [mailto:[EMAIL PROTECTED] I have a web app which serves both static and non static content, both secure and unsecure(https and http). Now, all my ssl configuration is under my secure virtual host, such that it applies to everything. However, I have quite a bit static content(images, css, javascript.,...) which doesn't need to be very secure. I somewhat only want to secure my dynamic content. To add to Cliff's comment about browsers complaining about the mix of secure an insecure content there is a genuine security reason for *not* doing what you propose. Put yourself in the position of a crook who has gained access to the datastream flowing into your SSL server. As you are probably aware, all encryption ciphers can be cracked by a brute force attack (making repeated attempts at guesssing the key). Hopefully, the time-to-crack will be long, but you don't know how fast the crook's computer is. If he works for the NSA, it might be very fast indeed. If you serve all content via SSL, he has no idea which packets are important and which are just images etc. so he has to crack everything. If you decide to save a teeny bit of processing on the server by encrypting only the important things, he then sees lots of en clair packets (containing image data etc.) which he can safely ignore and only a few occasional nuggets of encrypted data which he can be sure are worth cracking. Thus he can focus his efforts on these. Therefore, you make life easy for the cracker by highlighting the packets that are worth cracking! In other words, the best place to hide a leaf is in the forest. You shouldn't need to worry about the processing load of the SSL encryption. If it is slowing your server, then, frankly, your server is not powerful enough to serve the traffic you have - get more memory, upgrade the chipset, do whatever is necessary to get up to speed. Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. But, I don't want to generate absolute URLs on the fly to link to non-secure static content. What I want is to make request to certain urls less secure such that processing is faster. For example, I have a directory called art, which is just a defined alias for a directory. Is there a way to make ssl processing for this directory less restrictive than for the generic requests to the virtual host so that processing is faster? Home someone can help Henrik Bentel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Swiss Exchange. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Swiss Exchange. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière de la SWX Swiss
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: configuration question
At 02:22 AM 8/19/2003 -0400, you wrote:
On Wed, 20 Aug 2003, Henrik Bentel wrote:
Now, all my ssl configuration is under my secure virtual host, such that it
applies to everything. However, I have quite a bit static content(images,
css, javascript.,...) which doesn't need to be very secure. I somewhat only
want to secure my dynamic content.
If I understand your question correctly, what you're wanting is to have
some web page that's served up with https, but to have the images on that
page be served by regular http. You could do that, but every browser I
know of will throw a security warning in that case. You can't mix secure
and non-secure content in the same document.
Does that answer your question?
Hi
not quite.
I still want everything under https, but I was wondering if there is a way
to speed up processing per directory directive but still use https, such as
my image -directory.
Currently I have everything for ssl configured in the virtual host and
server config. SSL configuration included below.
Certificate is self signed from 1024 bit RSA key.
Listen 443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLPassPhraseDialog builtin
SSLSessionCache dbm:/var/opt/apache/run/ssl_scache
SSLSessionCacheTimeout 300
SSLMutex sem
#SSLMutex file:/var/opt/apache/run/ssl_mutex
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
ErrorLog /var/log/httpd/secure_error_log
CustomLog /var/log/httpd/secure_access_log common
LogLevel warn
VirtualHost 192.168.1.1:443
ServerName 192.168.1.1
DocumentRoot /opt/mydocRoot
ErrorLog /var/log/httpd/secure_error_log
TransferLog /var/log/httpd/secure_access_log
LogLevel warn
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXP56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /opt/app/conf/mycert.crt
SSLCertificateKeyFile /opt/app/conf/mycert.key
SetEnvIf User-Agent .*MSIE.* \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
#CustomLog /var/log/httpd/ssl_request_log %t %h %{SSL_PROTOCOL}x
%{SSL_CIPHER}x \%r\ %b
/VirtualHost
-Henrik Bentel
--Cliff
__
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
Boyle Owen [EMAIL PROTECTED] writes: -Original Message- From: Arthur Chan [mailto:[EMAIL PROTECTED] Hi Boyle, I've been debating with myself over whether to encrypt everything, that's a cogent argument you have offered. I have a few questions myself : (1) assuming an openssl encrypted packet is bigger than a plain text one, Why would you assume this? Essentially; encrypted_text = f(plain_text, key) where f() is a mathematical function. I guess the 2nd law of thermodynamics (entropy increases) would tend to cause the output to increase but not necessarily by much. In the simple case of a substitutional cipher, the encrypted text would be precisely the same size as the plain text. SSL-enciphered data is always somewhat larger than the plaintext. The overhead is from three sources: (1) the record header (5 bytes) (2) the MAC (16-20 bytes) (3) block cipher padding (if applicable). Note that all of this overhead is roughly fixed with respect to the record size (block cipher padding depends on the record size mod the block size). So, small records have enormous amounts of overhead (as high as 20 or more times for single-byte records). For large records the overhead is largely irrelevant. (e.g. 20/15000) If you're doing bulk data transfer you should always use large records. would mod_gzip shrink it significantly to warrant the effort? Zipping algorithms work by replacing repetitive sequences in the input with shorter instructions to regenerate them (e.g. 1000 blue pixels - 1 blue pixel x 1000). Compression works best with highly structured input data (bitmaps, WAV files, human language etc). With random data, it can't make much difference and will even cause the file to grow! (try repeatedly zipping a file to see this happening). One would apply mod_gzip PRIOR to encryption, so it will work unless the data is already pre-compressed (e.g. a GIF or a JPG). -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: configuration question
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. 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. You're forgetting the MAC. 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 PMTU is largely irrelevant here since SSL records can be much larger than the MTU. What's relevant here is the size of the SSL stream vis a vis the plaintext stream. -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: configuration question
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. --Cliff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: configuration question
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] Caveats ? And here is where I really get it, with this next question : I've got all this openssl key stuff working, and signed my own cert using openssl. On starting Netscape6.2 I got the little lock to close. I got Netscape to register my own site as a trusted site in WebSites But I want Netscape to load my certificate as an Authority for our testing purposes. How does one go about doing that, both in Netscape and MSIE5 ? TIA :-) - Original Message - From: Dave Paris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 07:58 PM Subject: 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
Re: configuration question
On Wed, 20 Aug 2003, Arthur Chan wrote: But I want Netscape to load my certificate as an Authority for our testing purposes. How does one go about doing that, both in Netscape and MSIE5 ? Google knows everything... an I'm feeling lucky for installing CA certificate yields: http://www.pseudonym.org/ssl/ssl_ca.html Which explains how to do just that. --Cliff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
http to https redirect configuration question
I am having a difficult time solving the following: I want our apache non-secure http:// server to redirect to the secure https:// server whenever the non-secure server encounters a .htaccess file in any directory? I do not want to redirect entire directories or the server itself, only those that contain a .htaccess file. The standard apache Redirect or RedirctMatch cannot do this because the .htaccess file is not typically specified by the user. You run into a looping problem if you specify a redirect in the .htaccess file itself. I was hoping there is some switch at the server level to do this. I of course searched all the docs and mailing archives for a solution. There is a solution using javascript in the index.html file that can do a redirect but this would have to be placed in everyone's .index file and there is no guarantee users will do this. Any solutions would be appreciated. Thanks. -- John W. Sopko Jr. University of North Carolina email: [EMAIL PROTECTED] Computer Science Dept., CB 3175 Phone: 919-962-1844 Sitterson Hall; Room 135 Fax: 919-962-1799 Chapel Hill, NC 27599-3175 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: http to https redirect configuration question
We have from time to time the following traces in our Apache logs : [Mon Feb 4 08:17:24 2002] [error] mod_ssl: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] (System error follows) [Mon Feb 4 08:17:24 2002] [error] System: Connection reset by peer (errno: 104) Can anyone help us finding what can the problem be related to ? Our apache is 1.3.20 mod_ssl 2.8.4 OpenSSL 0.9.6b. Part of our configuration is : IfModule mod_ssl.c # Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. SSLPassPhraseDialog builtin # Adding that line because of info from mod_ssl mailing list to # make more stable Apache SSL. # To my understanding (and anyone who can correct me if I am wrong, please do), # some versions of Microsoft Internet Explorer (MSIE) have problems with using the # HTTP/1.1 protocol with SSL. What this command does is to turn off keepalive # facility and force HTTP/1.0 responses (rather than HTTP/1.1 responses) when the # browser (User-Agent) is a version of MSIE. If you would like more information on # this, you might try the following page from the mod_ssl FAQ: # # http://www.modssl.org/docs/2.8/ssl_faq.html#ToC49 # IfModule mod_setenvif.c #SetEnvIf User-Agent .*MSIE.* nokeepalive \ ssl-unclean-shutdown downgrade-1.0 \ force-response-1.0 SetEnvIf User-Agent MSIE [1-4] nokeepalive \ ssl-unclean-shutdown downgrade-1.0 \ force-response-1.0 SetEnvIf User-Agent MSIE [5-9] ssl-unclean-shutdown /IfModule # # Inter-Process Session Cache: # Configure the SSL Session Cache: First either `none' # or `dbm:/path/to/file' for the mechanism to use and # second the expiring timeout (in seconds). #SSLSessionCachenone #SSLSessionCacheshm:/opt/apache/logs/ssl_scache(512000) SSLSessionCache dbm:/opt/apache/logs/ssl_scache SSLSessionCacheTimeout 300 # Semaphore: # Configure the path to the mutual explusion semaphore the # SSL engine uses internally for inter-process synchronization. SSLMutex file:/opt/apache/logs/ssl_mutex # Pseudo Random Number Generator (PRNG): # Configure one or more sources to seed the PRNG of the # SSL library. The seed data should be of good random quality. # WARNING! On some platforms /dev/random blocks if not enough entropy # is available. This means you then cannot use the /dev/random device # because it would lead to very long connection times (as long as # it requires to make more entropy available). But usually those # platforms additionally provide a /dev/urandom device which doesn't # block. So, if available, use this one instead. Read the mod_ssl User # Manual for more details. SSLRandomSeed startup builtin SSLRandomSeed connect builtin #SSLRandomSeed startup file:/dev/random 512 #SSLRandomSeed startup file:/dev/urandom 512 #SSLRandomSeed connect file:/dev/random 512 #SSLRandomSeed connect file:/dev/urandom 512 SSLEngine on SSLCipherSuite ALL:!ADH:!EXP56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # The certificate files are now located under /opt/apache/conf SSLCertificateFile /opt/apache/conf/XXX.crt SSLCertificateKeyFile /opt/apache/conf/XXX.key __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: http to https redirect configuration question
Take a look at the mod_rewrite docos. I remember seeing some test to see if a file exists (-f operator?). You could parse the URL's path to infer the physical directory and check to see if an .htaccess file exists there, and redirect appropriately to the SSL virtual server. Off the top of my head, a problem you might encounter is that you'd only have access to the virtual path (the URL's path), and not to the filesystem path, so you'd have to be very careful to take possible aliases into account. OTOH, if I had that need, I'd probably do something in a mod_perl handler (not a content handler, probably in an auth or access handler) because I'd have full access to the Apache API. Cheers... MZ -Original Message- From: John W. Sopko Jr. [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 10:49 To: [EMAIL PROTECTED] Subject: http to https redirect configuration question I am having a difficult time solving the following: I want our apache non-secure http:// server to redirect to the secure https:// server whenever the non-secure server encounters a .htaccess file in any directory? I do not want to redirect entire directories or the server itself, only those that contain a .htaccess file. The standard apache Redirect or RedirctMatch cannot do this because the .htaccess file is not typically specified by the user. You run into a looping problem if you specify a redirect in the .htaccess file itself. I was hoping there is some switch at the server level to do this. I of course searched all the docs and mailing archives for a solution. There is a solution using javascript in the index.html file that can do a redirect but this would have to be placed in everyone's .index file and there is no guarantee users will do this. Any solutions would be appreciated. Thanks. -- John W. Sopko Jr. University of North Carolina email: [EMAIL PROTECTED] Computer Science Dept., CB 3175 Phone: 919-962-1844 Sitterson Hall; Room 135 Fax: 919-962-1799 Chapel Hill, NC 27599-3175 __ 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
On Tue, May 02, 2000 at 12:12:44PM -0700, Brian J. Rohan wrote: In the mod_ssl manual, Chapter three covers various configurations directives. What config file are these directives added to in order to use them?? Can this config file be edited, saved, then stop the server, restart the server, and the changes take place, or do I need to re-compile the server?? The mod_ssl configuration directives are for use in the normal apache configuration file (usually /path/to/apache/conf/httpd.conf). As always the server must be restarted before the changes are loaded. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
configuration question
In the mod_ssl manual, Chapter three covers various configurations directives. What config file are these directives added to in order to use them?? Can this config file be edited, saved, then stop the server, restart the server, and the changes take place, or do I need to re-compile the server?? Brian __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: Configuration question: SSLRequire(SSL), how to *require* use of SSL
Hi, I've also recently set up an SSL site, whereby I wanted peiple who accidentally typed in "http://" URLs to be sent to the https site. It just needed the following virtual host, in addition to the SSL one. VirtualHost host01:80 ServerName managed-services.equant-web.net Redirect permanent / https://name-of-ssl-site/ /VirtualHost Where host01 is the name of the machine, and the SSL site was on VirtualHost host01:443. The following directives were needed above the VirtualHost clauses. NameVirtualHost host01:80 NameVirtualHost host02:443 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 12, 1999 3:51 AM To: [EMAIL PROTECTED] Subject: Configuration question: SSLRequire(SSL), how to *require* use of SSL Dear List Members, We have successfully installed Apache 1.3.6 with openssl 0.9.3a, and mod_ssl 2.3.3-1.3.6. We are using a httpd.conf file little changed from the one created by the installation. Having experimented, read the mail list archives, and read the manual at http://www.modssl.org/, there is still an issue that is confusing us. We would like to set things up in such a way that documents can only be accessed via https, and so that if a user references a document using http, he/she will be redirected to the same document via https. It would seem that SSLRequire and SSLRequireSSL should allow this, but we can't get them to work this way. I think what we need are some concrete examples of their use (the manual really needs examples, not just reference definitions). Anyone willing to share some experience? You can reply directly by email, and replies will be summarized and the summary sent back to the list. What we've done for the moment is create a top-level index.html file that redirects to the actual top-level document, but using a URL with https. Since we use only relative URLs within the document, as the user cruises around, everything is done using https. This works, but of course does not prevent a user from saving a url and accessing it later using http instead of https. Thanks in advance for any advice or pointers... Cheerio, Rick Rodgers __ 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: SSLRequire(SSL), how to *require* use of SSL
Thanks! This is exactly what I was after Cheerio, Rick Rodgers From [EMAIL PROTECTED] Mon Jul 12 11:22:43 1999 From: Yusef Badri [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Subject: RE: Configuration question: SSLRequire(SSL), how to *require* use of SSL Date: Mon, 12 Jul 1999 11:40:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-Sender: Yusef Badri [EMAIL PROTECTED] X-List-Manager: Majordomo [version 1.94.4] X-List-Name: modssl-users Hi, I've also recently set up an SSL site, whereby I wanted peiple who accidentally typed in "http://" URLs to be sent to the https site. It just needed the following virtual host, in addition to the SSL one. VirtualHost host01:80 ServerName managed-services.equant-web.net Redirect permanent / https://name-of-ssl-site/ /VirtualHost Where host01 is the name of the machine, and the SSL site was on VirtualHost host01:443. The following directives were needed above the VirtualHost clauses. NameVirtualHost host01:80 NameVirtualHost host02:443 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 12, 1999 3:51 AM To: [EMAIL PROTECTED] Subject: Configuration question: SSLRequire(SSL), how to *require* use of SSL Dear List Members, We have successfully installed Apache 1.3.6 with openssl 0.9.3a, and mod_ssl 2.3.3-1.3.6. We are using a httpd.conf file little changed from the one created by the installation. Having experimented, read the mail list archives, and read the manual at http://www.modssl.org/, there is still an issue that is confusing us. We would like to set things up in such a way that documents can only be accessed via https, and so that if a user references a document using http, he/she will be redirected to the same document via https. It would seem that SSLRequire and SSLRequireSSL should allow this, but we can't get them to work this way. I think what we need are some concrete examples of their use (the manual really needs examples, not just reference definitions). Anyone willing to share some experience? You can reply directly by email, and replies will be summarized and the summary sent back to the list. What we've done for the moment is create a top-level index.html file that redirects to the actual top-level document, but using a URL with https. Since we use only relative URLs within the document, as the user cruises around, everything is done using https. This works, but of course does not prevent a user from saving a url and accessing it later using http instead of https. Thanks in advance for any advice or pointers... Cheerio, Rick Rodgers __ 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: Configuration question: SSLRequire(SSL), how to *require* use of SSL
11-Jul-99 22:51 you wrote: Dear List Members, We have successfully installed Apache 1.3.6 with openssl 0.9.3a, and mod_ssl 2.3.3-1.3.6. We are using a httpd.conf file little changed from the one created by the installation. Having experimented, read the mail list archives, and read the manual at http://www.modssl.org/, there is still an issue that is confusing us. We would like to set things up in such a way that documents can only be accessed via https, and so that if a user references a document using http, he/she will be redirected to the same document via https. It would seem that SSLRequire and SSLRequireSSL should allow this, but we can't get them to work this way. I think what we need are some concrete examples of their use (the manual really needs examples, not just reference definitions). Anyone willing to share some experience? You can reply directly by email, and replies will be summarized and the summary sent back to the list. SSLRequireSSL will prevent your from accidently accessing protected documents via HTTP (instead of HTTPS). That's all. Nothing more. No automatic redirects. If you really need them then you'll need mod_rewrite ... What we've done for the moment is create a top-level index.html file that redirects to the actual top-level document, but using a URL with https. Since we use only relative URLs within the document, as the user cruises around, everything is done using https. This works, but of course does not prevent a user from saving a url and accessing it later using http instead of https. Thanks in advance for any advice or pointers... You need SSLRequireSSL (just in case: to prevent accessing via HTTP) and redirect via mod_rewrite ... __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Configuration question: SSLRequire(SSL), how to *require* use of SSL
Dear List Members, We have successfully installed Apache 1.3.6 with openssl 0.9.3a, and mod_ssl 2.3.3-1.3.6. We are using a httpd.conf file little changed from the one created by the installation. Having experimented, read the mail list archives, and read the manual at http://www.modssl.org/, there is still an issue that is confusing us. We would like to set things up in such a way that documents can only be accessed via https, and so that if a user references a document using http, he/she will be redirected to the same document via https. It would seem that SSLRequire and SSLRequireSSL should allow this, but we can't get them to work this way. I think what we need are some concrete examples of their use (the manual really needs examples, not just reference definitions). Anyone willing to share some experience? You can reply directly by email, and replies will be summarized and the summary sent back to the list. What we've done for the moment is create a top-level index.html file that redirects to the actual top-level document, but using a URL with https. Since we use only relative URLs within the document, as the user cruises around, everything is done using https. This works, but of course does not prevent a user from saving a url and accessing it later using http instead of https. Thanks in advance for any advice or pointers... Cheerio, Rick Rodgers __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
