Re: rfc2817 (Upgrading to TLS Within HTTP/1.1)
Mads Toftum <[EMAIL PROTECTED]> writes: > On Mon, May 22, 2000 at 01:14:03PM -0500, James H. Cloos Jr. wrote: > > Any idea of a timeframe for rfc2817 support? > > > > (I'd offer to help, but I still do not trust the us export issues, > > even though I am abroad at the moment) > > > > It seems straightforward, though it looks like for clients to support > > it well, they also need good support for persistant connections > > > It would probably make sense to wait for openssl to support this and > IMHO without clients there really is no need to work on this yet. I > don't really think we're going to see this anytime soon unless M$ > suddenly decides to do something like it. It doesn't make sense for OpenSSL to support it. It's a purely HTTP feature. That said, I agree that it's probably not worth doing at this time. It's not likely to be suported by browsers any time soon. In fact, if you read rfc2817, it implies as much: In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol [7], call for just such a mechanism in order to move ahead in the IETF standards process. -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Certificate questions...
Jon Earle <[EMAIL PROTECTED]> writes: > At 07:36 AM 3/7/00 -0800, you wrote: > >Karl Denninger <[EMAIL PROTECTED]> writes: > > > Well, confidentiality implies integrity, in that a tampered data stream > > > won't decode. Public key crypto with a known certification on the public > > > key provides non-repudiation (assuming the private key has not been > > > compromised) > > >This is absolutely not true. > > > >Consider a data stream enciphered with RC4. It's perfectly > >easy to undetectably flip any plaintext bit by > >flipping the corresponding ciphertext bit. If you know the > >plaintext, you can modify it predictably. > > Perhaps... but isn't this impractical? The key phrase here is "If you know the > plaintext...". If you know the plaintext you can make PREDICTABLE changes. Without the plaintext, you can make arbitrary undetected changes. > How would one know if a random, encrypted stream is a > recipe, a love letter, or a secret message to religious extremists? It all > just looks like encrypted packets. You can tell an incredible amount from traffic analysis. For instance, connections on port 443 are almost always HTTP over SSL. If you've been looking at the previous HTTP traffic between this client and server pair, you can often get a pretty good idea of what the first encrypted message is. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Certificate questions...
Karl Denninger <[EMAIL PROTECTED]> writes: > On Tue, Mar 07, 2000 at 12:23:33AM +0100, Jan Meijer wrote: > > Hi Karl, > > > > Whilst taking the risk to look like someone from Microshot, Netscape or the > > others some comment on your pleads for clarity. > > > > > There are to separate things that secure web servers do. > > > > > > 1. Authenticate who you're talking to, so that when you engage in > > > commerce you have some indication that the merchant you think you're > > > dealing with is really who you're dealing with. > > > > > > 2. Encrypt the data so that it cannot be intercepted between the > > > sending and receiving machines. > > > > True. Crypto allows for two other quite basic functions: non-repudiation > > and integrity. You only mentioned authenticity and confendiatlity. > > Well, confidentiality implies integrity, in that a tampered data stream > won't decode. Public key crypto with a known certification on the public > key provides non-repudiation (assuming the private key has not been > compromised) This is absolutely not true. Consider a data stream enciphered with RC4. It's perfectly easy to undetectably flip any plaintext bit by flipping the corresponding ciphertext bit. If you know the plaintext, you can modify it predictably. > The "man in the middle" risk is a red herring. As long as the CA vouches > for the key exchange its "cool", and you'd only detect the man in the middle > attack if you actually LOOKED at each certificate for each page served. > > How many people click on the padlock and LOOK at each page's certificate? > Without a warning nobody checks - and as such the risk is still there. This is incorrect. The browser has automatic checks that the certificate matches the server's domain name. These checks aren't perfect, but they're not useless either. If these checks didn't exist then it would be necessary to check every certificate manually. That would be bad. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Certificate questions...
Karl Denninger <[EMAIL PROTECTED]> writes: > On Mon, Mar 06, 2000 at 02:10:42PM -0800, EKR wrote: > > The generation, no. However, in order for people sending you mail > > to be sure that they are not subject to active key substitution > > attacks, they key pair does need to be securely bound to the > > recipient. Unless you're prepared to exchange keys with all of your > > correcpondents out of band, you do need third party key certification. > > PGP accomplishes this using key signing rather than certificates > > per se, but it's an analagous concept. > > Understood. > > However, the concept that a PERSON needs to pay upwards of $100 to get a key > by which they can have a SSL connection work from a web server is insane. > > Why are there no public CAs - much like the public keyrings for PGP? > > Why does Nutscrape and Microslug only ship with COMMERCIAL, and EXPENSIVE, > CAs loaded? I can't speak for the rationales behind MS or NSCP's policies, but I don't think this is as simple as you make it out to be. The issue is maintaining reference integrity for HTTPS transactions. The client has in hand a URL of the form <https://www.example.com/>. When he connects to the server, the server presents his certificate. This certificate should have the identity "www.example.com" (in the CN field). If it doesn't, then the browser will pop up a dialog complaining about this. The reason for this check is (once again) to prevent active substitution attacks whereby someone with a legitimate certificate for a different e.g. "www.attacker.com" poses as the server. In order for this procedure to work correctly, the CAs must enforce the binding between domain name and identity in certificate. If they don't, then active attacks are possible. Thus, any CA trusted by MS or NSCP must agree to these rules. But enforcing them is irritating and expensive. I don't know of any non-commercial CA who promises to do so. Your comparison to PGP keyservers really isn't apt. PGP keyservers are more like LDAP directories than CAs. The provider of the keyserver doesn't vouch for the keys, he simply serves them. The signatures on the keys are (usually) those of individuals. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Certificate questions...
Karl Denninger <[EMAIL PROTECTED]> writes: > Well, I understand that, but it seems that people (including Thawte, > Microslug and Nutscrape) are missing the point. > > There are to separate things that secure web servers do. > > 1.Authenticate who you're talking to, so that when you engage in > commerce you have some indication that the merchant you think you're > dealing with is really who you're dealing with. > > 2.Encrypt the data so that it cannot be intercepted between the > sending and receiving machines. > > These are NOT the same function, and needing one of them does not imply > needing the other. This is incorrect. Without authentication of the merchant's identity, you're subject to a variety of active attacks where the attacker substitutes his key for the merchant's. You can only have encryption without endpoint authentication if your threat model does not include active attack. > Yet, in today's world, you cannot have one without the other, which means > that to get EITHER you must pay someone. > > Contrast this with PGP for email, in which I can publish a public key and > once you obtain it you're able to receive an encrypted communication from > me and decode the traffic. My generation of that key pair does not require > that it be "certified" by any third party. The generation, no. However, in order for people sending you mail to be sure that they are not subject to active key substitution attacks, they key pair does need to be securely bound to the recipient. Unless you're prepared to exchange keys with all of your correcpondents out of band, you do need third party key certification. PGP accomplishes this using key signing rather than certificates per se, but it's an analagous concept. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problem with Global Server ID - SGC
vijay karthik <[EMAIL PROTECTED]> writes: > Hi ! > > I am facing a problem while configuring Global server > certificate - SGC support ! > > 1> I got a verisign Global Serv ID(for SGC) : gsid.crt > 2> specified the gsid.crt under SSLCertificateFile > 3> specified the key file > 4> Got the intermediate verisign CA root(gsid_ca.crt) > and specified the same under > SSLCertificateChainFile. > 5> started apache: apachectl startssl > > I installed 4.08 netscape browser with SCG support. > Selected the cipher - "RC4 encryption with a 128-bit > key and an MD5 MAC (When permitted)" ! I unselected > every other cipher from the browser.i expected a > step-up. The browser gave an error when connecting to > apache server. > > "You cannot connect to an encrypted website because > SSL has been disabled. you can enable SSL from > security->navigator option...etc" > > Whereas if i select a cipher "RC4 encryption with a > 40-bit key and an MD5 MAC" then the connection goes > thru fine. This means still the stepup doesnt work! Actually, this is what's supposed to happen. To understand why, you need to understand Step-Up. The way that Step-Up works is that the client and server first negotiate an SSL connection with an export cipher. If the server has a Step-Up capable certificate, the client then initiates a rehandshake with a strong cipher. Thus, since you've removed all the export ciphers from the cipher list, the first handshake fails and the whole process doesn't work. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: no common encryption algorithm(s)
Maik Mueller <[EMAIL PROTECTED]> writes: > Hello, > > First of all, sorry for opening this discussion again! > But I want to ask a very precise question: > > I use SLCipherSuite NULL-MD5 (nothing else). > > Using an RSA Key/Cert it works: > Init: Configuring server p24958:9443 for SSL protocol > Init: (p24958:9443) Creating new SSL context (protocols: SSLv3) > Init: (p24958:9443) Configuring permitted SSL ciphers [NULL-MD5] > Init: (p24958:9443) Configuring RSA server certificate > [...] > Connection: Client IP: 155.56.94.132, Protocol: SSLv3, Cipher: NULL-MD5 (0/0 > bits) > > Using a DSA Key/Cert it does not work: > Init: Configuring server p24958:9443 for SSL protocol > Init: (p24958:9443) Creating new SSL context (protocols: SSLv3) > Init: (p24958:9443) Configuring permitted SSL ciphers [NULL-MD5] > Init: (p24958:9443) Configuring DSA server certificate > [...] > SSL handshake failed (server p24958:9443, client 155.56.94.132) (OpenSSL > library error follows) > OpenSSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher > [Hint: Too restrictive SSLCipherSuite or using DSA server certificate?] > > >From my point of view there is no reason why NULL-MD5 should not be a shared > cipher in both cases (RSA and DSA). There are no ciphersuites with DSA and NULL_MD5 defined by SSL. Therefore it is not possible to negotiate them. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Global Server ID(how to issue my own)
"William X. Walsh" <[EMAIL PROTECTED]> writes: > On 01-Feb-2000 [EMAIL PROTECTED] wrote: > >> I haven't any wish to trust & to pay to Verisign. > >> How can I issue my own Global Server ID certificate for use in closed > >> intranet group in order to force none-US browsers (40 bit) to > >> connect using > >> 128bit-strong security SSL connection?(refer to Netscape > >> "Step-up"&Microsoft > >> "SGC"). > > > > You can't do that. It has to be signed by Verisign (or one of the other > > companies that are allowed to issue GSID. > > Allowed by who?? > > That seems pretty weak to me. If they can issue a cert of this type, I see no > reason why others can't as well. Maybe there is something I am missing, but > who is it that decides who is "allowed to issue GSID" ? The US Government. The whole point of the exercise is to allow strong crypto for financial transactions but nothing else. For this to work properly, the certificates have to vouch for the server being used for financial purposes. But that means that the CA has to be trusted by the government not to issue these special certificates to just anyone. Which means that only certain (trusted) CAs can issue them. The technical enforcement of this, of course, is done by Netscape and MS, but they're restricted in what they can do by the feds, who can refuse export licenses if the software doesn't behave the way they like. Of course, all this is probably moot in the face of the new export liberalization. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Diffie-Hellman Key Exchange again.
Jeffrey Altman <[EMAIL PROTECTED]> writes: > > That kinda sucks, doesn't it? > > > > > Once again, using anonymous DH is a really terrible idea. > > > It leaves you completely open to active attack. > > > > That might be the case, but it's far better than no crypt at all. > > I could imagine the effect of using ADH is similar to using SSH without RSA. > > Or is it even worse? > > Actually, using Anonymous DH is about as bad as using SSH (with or > without public authentication). Both leave you open to man in the > middle attacks in which you believe you are talking to the host you > desire, but really you are talking to the man in the middle who has > then established as connection to the host you want to chat with. > > The attacker just sits there in the middle decrypting, storing, and > re-encrypting all of the data. I don't believe this is correct. SSH keeps a record of the public keys for known machines. It won't connect to machines with unknown key sunless you tell it to explicitly. So, if you arrange to obtain the public keys of machines you wish to connect to securely (not that hard) then you should not be subject to a man-in-the-middle attack.. Even if you are connecting for the first time over an open network, SSH allows you to store the server keys so you're only at risk for man-in-the-middle once. This is significantly better than anonymous DH where you're always at risk. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Diffie-Hellman Key Exchange again.
Kenneth Mutka <[EMAIL PROTECTED]> writes: > > As I said in my previous mail, IE 5 Under Win2K supports > > DSS/DH. > > > > It does not, however, as far as I know, support anonymous > > DH. > > That kinda sucks, doesn't it? I think that depends on your perspective. There's an argument to made that bad security is worse than no security at all. > > Once again, using anonymous DH is a really terrible idea. > > It leaves you completely open to active attack. > > That might be the case, but it's far better than no crypt at all. That completely depends on your threat model. If what you're concerned with is sniffing, yes. If what you're concerned with is active attack via session hijacking, DNS spoofing, etc., then no, it's no better. > I could imagine the effect of using ADH is similar to using SSH without RSA. > Or is it even worse? If you mean SSH mode where the server has an RSA key but the client does not, then the answer is that it's far far worse. In the SSH case, the attacker still can't get at your password -- provided that you check the server's RSA key against the one you know matches that server. With SSL and ADH, an active attacker can recover any data you send over the channel. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Diffie-Hellman Key Exchange again.
Kenneth Mutka <[EMAIL PROTECTED]> writes: > > Neither Netcape 4.7 nor IE 5 supports DH key exchange. It is not > > required by SSLv3. > > If they don't support it, what browsers does? > I would like to run Anonymous Diffie-Hellman aswell. As I said in my previous mail, IE 5 Under Win2K supports DSS/DH. It does not, however, as far as I know, support anonymous DH. Once again, using anonymous DH is a really terrible idea. It leaves you completely open to active attack. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: HELP! Diffie-Hellman Key Exchange
john easton <[EMAIL PROTECTED]> writes: > I do not want to use certificates. It is my understanding that in order > to run an encrypted site without certificates, it is necessary to use > Diffie-Hellman key exchange. I have done this (make certificate, > specifying 'D' at the first prompt), and I have changed my > SSLCipherSuite directive to the following in order to allow > Diffie-Hellman ciphers (I think!) > > SSLCipherSuite ALL:!RSA:DH:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP > > Neither Netscape 4.7 nor IE5 can connect to the web server under these > conditions, although both claim to support SSLv3 (which Diffie-Hellman > is a part of, I believe). I know it's possible to run a secure web > server without certificates as I have been to numerous sites which do > so. > > Can anyone tell me what I'm doing wrong here? Neither Netcape 4.7 nor IE 5 supports DH key exchange. It is not required by SSLv3. IE 5 under Win2K does support the TLS DSS/DH cipher suites (as required by TLS) but it does not support anonymous DH like you're trying to do. It's actually not possible to run a secure web site without certificates since it opens you to a man in the middle attack. I don't know what you think you've seen. If you don't care about man-in-the-middle, you can issue yourself a self-signed RSA certificate. This would require the client to click in some dialog to accept it, however. Incidentally, your configuration isn't right for anonymous DH either. You'd (at minimum) need to turn on the ADH cipher suites using +ADH or somesuch. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Lowest encryption setting?
"Joseph R. Junkin" <[EMAIL PROTECTED]> writes: > EKR wrote: > > Now, not all 56-bit modes are equally fast. RC4 in 56 mode > > (one of the experimental cipher suites) > > All I am concerned with right now are what is supported by typical IE > and Netscape users, both US and non-US. > So then should I not be concerned with RC4 then because it is > experimental? I didn't say that. What I said was that RC4-56 was experimental. On the other hand, you might as well support it because it isn't any slower. > > is going to be much > > faster than DES-56. On the other hand 3DES (168 bit) is going > > to be 3 times as slow as DES. > > Does the typical browser support 3DES? I thought 128 bit encryption was > it for the moment. Yes, the domestic browsers typically support 3DES. > > > Bottom line, what is/are the setting(s) that will place the lowest > > > possible load on my server, assuming that I already have my certificate > > > (www.datafree.com)? > > I think youre overrating the effect of the symmetric cipher > > on server load. > > Could be, but doesn't SSL add quite a bit compared to non-SSL? Yes, but it's the asymmetric cipher (RSA) that adds the load if you're doing alot of connections but not a lot of data per connection. > >Do you know that load is a problem? > > No, it is not yet. I am providing a free service with information that > can be *read* by guests, unencrypted via non-SSL. So encrypting the data > just doesn't matter. > Yet when users want to contribute or update their own information, they > must login. > Users may also be administrators, so I want pretty good security for the > login as well as the session. > I have designed this with secure cookies and it seems to work well. The encryption in SSL is the same from client to server as from server to client. If you're using passwords or cookies, then you should be concerned with having good encryption since you don't want them sniffed. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Lowest encryption setting?
Simon Weijgers <[EMAIL PROTECTED]> writes: > > However, if you're talking to an export browser then you'll > > end up with 512 bits of security but it will be as slow > > as 768 bits because of ephemeral RSA mode. [0] > > > > -Ekr > > > > [0] Yes, I know that 512 bit ephemeral RSA isn't exactly > > the same security wise as 512 bit static, but they're > > close to a first order. > Actually with mod_ssl ephemeral is really not so ephemeral. > It's generated only once at startup. So ephemeral is as long > as the uptime of apache which usually is quite long. Yes, I know. So, the security isn't any better but there is still a performance penalty because you have to perform both the 1024 bit signature and the 512 bit decryption. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Lowest encryption setting?
"Joseph R. Junkin" <[EMAIL PROTECTED]> writes: > EKR wrote: > > > > "Joseph R. Junkin" <[EMAIL PROTECTED]> writes: > > > I want to run a site with the lowest possible encryption for the highest > > > performance. > > Encryption and performance are not mutually opposed in the way > > you might think. > > OK, but why not? I am quite new to this (still learning) and do not > understand why. I would assume that the system would work twice as hard > to generate 128 bit SSL compared to 56 bit SSL. Ok, the answer to your literal question is simple: SSL uses EXACTLY the same algorithm for RC4-40 as RC4-128. It simply expands the 40 bit key to a 128 bit key before feeding it to RC4. Thus, it's not any faster to use 40 bits. Actually it's very slightly slower because the expansion takes some time. Now, not all 56-bit modes are equally fast. RC4 in 56 mode (one of the experimental cipher suites) is going to be much faster than DES-56. On the other hand 3DES (168 bit) is going to be 3 times as slow as DES. > > In the case of symmetric ciphers, RC4 is by far the fastest > > and it's no slower in 128 bit mode than 40 bit mode. Thus, > > I'd advise you to use RC4-128. > > OK, I followed the steps for a US installation which included RSA. Can I > still use RC4-128? Yes. > Would the configuration be: > SLCipherSuite ALL:!ADH:RC4-RSA:-HIGH:-MEDIUM:+LOW:+SSLv2:+EXP > ?? I doubt it. What you want to do here is to use RC4-128 whenever possible but use RC4-40, DES, or 3DES (in that order) when necessary. Surely you don't want to not talk to clients just because they will only speak a slower cipher. I'm not sure enough about how OpenSSL negotiates to advise you on how to set this. It may not be possible to tell it what order to choose ciphers in. Sorry. I'm fairly sure this is wrong, however, since you've turned off all the high security ciphers. > Well, I have already created my key and received my cert from thawte for > www.datafree.com > I assume that I used the default settings which would be 1024?? I think it is. Ralf? > Bottom line, what is/are the setting(s) that will place the lowest > possible load on my server, assuming that I already have my certificate > (www.datafree.com)? I think youre overrating the effect of the symmetric cipher on server load. Are you moving enormously large files? Do you know that load is a problem? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Lowest encryption setting?
"Joseph R. Junkin" <[EMAIL PROTECTED]> writes: > I want to run a site with the lowest possible encryption for the highest > performance. I want it to work with typical browsers (Netscape4 & IE4) > Right now I am using: > SLCipherSuite ALL:!ADH:RC4+RSA:-HIGH:-MEDIUM:+LOW:+SSLv2:+EXP > > When I access it using IE5, it tells me that it is connecting at 56 bit. > I am aware that some older export browsers do 40bit, is there a way to > force 40 bit for all browsers? > > Anything I can do for maximum performance while still using some form of > widely accepted encryption? Encryption and performance are not mutually opposed in the way you might think. In the case of symmetric ciphers, RC4 is by far the fastest and it's no slower in 128 bit mode than 40 bit mode. Thus, I'd advise you to use RC4-128. As far as asymmetric ciphers goes, RSA is substantially faster than DSA/DH. You control your RSA key length so you'll have to decide how large an RSA key to generate. 512 is known to be breakable by a dedicated effort using today's technology. I'd advise 768 bits as the minimum myself. However, if you're talking to an export browser then you'll end up with 512 bits of security but it will be as slow as 768 bits because of ephemeral RSA mode. [0] -Ekr [0] Yes, I know that 512 bit ephemeral RSA isn't exactly the same security wise as 512 bit static, but they're close to a first order. -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: HTTPS with Client Authentication -> HTTP
[EMAIL PROTECTED] (Joe McMahon) writes: > > It'd require being a little sneaky, but I'd think a good way to go about > > this would be setting a cookie with a session identifier with a 0 > > expiration. Of course, this is only as trustworthy as the network, > > because anybody sniffing the wire after the session switches to HTTP can > > steal the session ID cookie and start using it, posing as your > > "authenticated" client. > > > Getting a little more sneaky will make it work. > > Quoting directly from Mark_Jason Dominus' WWW security tutorial: > >If you get a request that doesn't contain a cookie at all, redirect >the browser to a login page with a fill-out form with 'username' and >'password' boxes. If they send the right username and password, bake >up a cookie with the following ingredients: > >A. Username >B. User's IP address >C. Expiration time (if desired) >D. Secret data known only to you >E. MD5(A,B,C,D) > >F. The cookie: Concatenate A, B, C, and E. (Don't include D. It's > secret!) > >If the user _does_ show up with a cookie, you get F, which contains >the items ABCE. Check C, the expire time, and fail if C is in the >past. Checnk B, the expected IP address, and fail if it doesn't >match the browser's actual IP address. Look up D, compute the MD5 >hash of A, B, C, and D, and fail if this doesn't match E, the >expected hash. Finally, if everything has checked out, take A, the >username, and use it as the user's identity. > >If some snooper stelas the cookie F, it won't do them much good. F >contains B, the user's IP address, so it can only be used from the >correct IP address. The user can't tamper with B, because that >would mess up the checksum E. They can't forge a new checksum, >because the checksum includes D, which they don't know. D is never >transmitted anywhere, is kept under strict lock and key at your >site, and is changed immediately if it ever leaks. This still isn't that secure. It's actually trivial to generate traffic with IP addresses of your choice. Under a lot of conditions, it's easy to arrange to receive the return traffic as well. Imagine, for instance, that the attacker is on the same network as the machine he's trying to impersonate. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Win32: Hang on password reading
"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes: > On Sun, Oct 03, 1999, Eric Rescorla wrote: > Yes, someone else also reported that the pass phrase dialog doesn't work > correctly under Win32. But I cannot fix it myself, because I've both no real > Win32 development environment available nor the knowledge to find out what > Win32 dislikes in the mod_ssl/OpenSSL dialog. And I have also to admit that > fixing Win32-*only* bugs is maximum low-priority on my TODO list, of course. > > So if you want the dialog fixed for Win32, you have to help me in finding out > the problem. Where are the Win32 hackers under us? Can someone help us here > and provide a patch to make the dialog working under this Win32 environment? Ok, I've got the problem debugged somewhat more fully. Password _reading_ works fine. What doesn't work is that the prompt isn't getting printed. EVP_read_pw_string() writes it's prompt to stderr, but at this stage in the game, stderr has already been remapped. To accomodate this, mod_ssl dup2()s stdout onto stderr, but stdout has also been redirected under Win32. (I don't know where) so this doesn't help. I've successfully been able to open "con" in write mode and write there, but for some reason the obvious handoff to stderr with dup2() isn't working correctly. I suspect I've made some trivial mistake, but I'm not sure what it is. That said, if you blindly type in the password, the server starts no problem, so it's easy to make it workable, if a little ugly. If I manage to produce a shippable patch, I'll post it. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mod_ssl 2.3.5 totaly broken on Win32
"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes: > On Thu, Sep 30, 1999, EKR wrote: > > > [..] > > > mod_ssl.c(207) : error C2078: too many initializers > > > NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' > > > Stop. > > > NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual > > > Studio\VC98\bin\NMAKE > > > .EXE"' : return code '0x2' > > > Stop. > > > > > > AP_MM under Win32 ? > > I get the result that you're describing with 2.4.5 when > > I compile 2.4.4. > > > > Upon debugging, I determined that the patch program > > (etc\patch) is broken under 2.4.4. When run from the > > command line it produces the output: > > "This program cannot be run in DOS mode". > > > > Unfortunately, when run under configure.bat, it fails > > silently. > > > > As a consequence, none of the Apache files that are > > changed with patch get changed. This includes httpd.h. > > As a consequence, httpd.h doesn't include "ap_mm.h", > > which defines AP_MM. > > > > When I replaced the patch with the patch from Apache 2.4.2, > > things compile corectly. Under very light testing, > > they don't seem to crash. > > Errr.. the patch.exe wasn't changed for over one year: > > -rw-r--r-- 1 rse wheel 96256 Oct 21 1998 patch.exe > > So something else has to be broken for you, but not this program. Perhaps > you've messed up the distribution on download or whatever else. Yes, you're absolutely right. I broke it by unintentionally linefeed converting. Nevertheless, the symptoms that Mr. Reichenbach describes wrt AP_MM are (likely) the result of the patches not being applied. I'm not sure why it would have happened for him, though. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mod_ssl 2.3.5 totaly broken on Win32
"Daniel Reichenbach" <[EMAIL PROTECTED]> writes: > i tested mod_ssl 2.4.3, 2.4.4 and 2.4.5 Snapshot on Win32. Its totally > broken. 2.4.3 and 2.4.4 cause a page fault in OpenSSL, each time a > connection is established. > > mod_ssl 2.4.5 doesn`t even compile. It produces the following output, > using Visual C++6 plus Service Pack 3: > > cl.exe /nologo /c /O2 /MD /W3 /GX /DNDEBUG /DWIN32 /D_WINDOWS > /DSHARED_MODULE /DEAPI /DMOD_SSL=204105 /DMOD_SSL_VERSION=\"2.4.5\" > /I..\..\include /IC:\Programme\OpenSSL\include mod_ssl.c > mod_ssl.c > mod_ssl.h(515) : error C2061: syntax error : identifier 'AP_MM' > mod_ssl.h(530) : error C2059: syntax error : '}' > mod_ssl.c(207) : error C2078: too many initializers > NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual > Studio\VC98\bin\NMAKE > .EXE"' : return code '0x2' > Stop. > > AP_MM under Win32 ? I get the result that you're describing with 2.4.5 when I compile 2.4.4. Upon debugging, I determined that the patch program (etc\patch) is broken under 2.4.4. When run from the command line it produces the output: "This program cannot be run in DOS mode". Unfortunately, when run under configure.bat, it fails silently. As a consequence, none of the Apache files that are changed with patch get changed. This includes httpd.h. As a consequence, httpd.h doesn't include "ap_mm.h", which defines AP_MM. When I replaced the patch with the patch from Apache 2.4.2, things compile corectly. Under very light testing, they don't seem to crash. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
