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 > dependent on how much compression you're getting. If you can take a 100K > document and compress it to 25K, that's a 75% reduction in the amount of > data SSL needs to encrypt and reduces the number of packets from about 66 to > around 16 - again, not including the SSL handshake/setup and general TCP > setup/teardown. > > If you're bogging down your server with all the SSL transactions, look at > investing in a SSL accelerator. If your business model depends on both > security *and* performance, then the cost (starting around 20K$USD) should > be easily justified. But that's the subject of another mail and I've got > some coffee getting cold over here. ;-) > > Hope this didn't glaze your eyes over. :-) > Best~ > -dsp > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Boyle Owen > Sent: Tuesday, August 19, 2003 7:02 AM > To: [EMAIL PROTECTED] > Subject: RE: configuration question > > > > > >-----Original Message----- > >From: Arthur Chan [mailto:[EMAIL PROTECTED] > > > >Hi Boyle, > >I've been debating with myself over whether to encrypt > >everything, that's a > >cogent argument you have offered. I have a few questions myself : > >(1) assuming an openssl encrypted packet is bigger than a > >plain text one, > > Why would you assume this? Essentially; > > encrypted_text = f(plain_text, key) > > where f() is a mathematical function. I guess the 2nd law of thermodynamics > ("entropy increases") would tend to cause the output to increase but not > necessarily by much. In the simple case of a substitutional cipher, the > encrypted text would be precisely the same size as the plain text. > > >would mod_gzip shrink it significantly to warrant the effort? > > Zipping algorithms work by replacing repetitive sequences in the input with > shorter instructions to regenerate them (e.g. 1000 blue pixels -> "1 blue > pixel x 1000"). Compression works best with highly structured input data > (bitmaps, WAV files, human language etc). With random data, it can't make > much difference and will even cause the file to grow! (try repeatedly > zipping a file to see this happening). > > >(2) and would that slow down the client browser display of content ? > > Unzipping requires the client to have winzip - not a default on a windows > client! Probably this would slow the whole thing down. > > Remember that SSL is well-defined on the web and all recent browsers contain > fast and effective SSL software - I would trust it to do its job and not try > to re-invent the wheel. > > Rgds, > Owen Boyle > Disclaimer: Any disclaimer attached to this message may be ignored. > > >On the other hand, with these new 1GHz+ P4 desk- and lap-tops > >around, maybe > >not. > > > >----- Original Message ----- > >From: "Boyle Owen" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Tuesday, August 19, 2003 04:49 PM > >Subject: RE: configuration question > > > > > >>-----Original Message----- > >>From: Henrik Bentel [mailto:[EMAIL PROTECTED] > >> > >>I have a web app which serves both static and non static content, both > >>secure and unsecure(https and http). > >>Now, all my ssl configuration is under my secure virtual host, > >>such that it applies to everything. However, I have quite a bit static > >>content(images, css, javascript.,...) which doesn't need to be very > >secure. I > >>somewhat only want to secure my dynamic content. > > > >To add to Cliff's comment about browsers complaining about the mix of > >secure an insecure content there is a genuine security reason for *not* > >doing what you propose. > > > >Put yourself in the position of a crook who has gained access to the > >datastream flowing into your SSL server. As you are probably aware, all > >encryption ciphers can be cracked by a brute force attack (making > >repeated attempts at guesssing the key). Hopefully, the time-to-crack > >will be "long", but you don't know how fast the crook's computer is. If > >he works for the NSA, it might be very fast indeed. If you serve all > >content via SSL, he has no idea which packets are important and which > >are just images etc. so he has to crack everything. If you decide to > >save a teeny bit of processing on the server by encrypting only the > >important things, he then sees lots of "en clair" packets (containing > >image data etc.) which he can safely ignore and only a few occasional > >nuggets of encrypted data which he can be sure are worth cracking. Thus > >he can focus his efforts on these. Therefore, you make life > >easy for the > >cracker by highlighting the packets that are worth cracking! In other > >words, the best place to hide a leaf is in the forest. > > > >You shouldn't need to worry about the processing load of the SSL > >encryption. If it is slowing your server, then, frankly, your server is > >not powerful enough to serve the traffic you have - get more memory, > >upgrade the chipset, do whatever is necessary to get up to speed. > > > >Rgds, > >Owen Boyle > >Disclaimer: Any disclaimer attached to this message may be ignored. > > > >>But, I don't want to generate absolute URLs on the fly to link to > >>non-secure static content. What I want is to make request to > >>certain urls > >>"less secure" 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) 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. > > ______________________________________________________________________ > 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]
