Michael, you really need to read this: http://cgi.fr.netscape.com/eng/ssl3/traces/index.html It's the draft spec for SSL 3. It's old, but AFAIK it's still TFM. Note that the rest of my stuff is still inside the <clueless on> tag. Don't trust me - I'm free. > -----Original Message----- > From: me [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 21 October 1999 7:13 AM > To: [EMAIL PROTECTED] > Subject: Once again...please! > > > To all, [snip] > So here goes another (humbling again I'm sure) attempt to map > out what happens during a SSL session. Please feel free to > read and comment on any part(s) you wish. After everyone's > done suggesting, I'll be re-doing this and then using it as > the foundation of fact for information that will ultimately > flow to our board members and members. Rights? Attributation? 8) > <clueless on> > Browser verifies the validity of the web servers' digital > certificate with Verisign or some other authenticating authority. > Browser asks the web server for two things: Nope. The setup stage includes a client hello which must be followed by a server hello. The client hello includes thingts like the SSL version, supported ciphers (in order of preference) and some random stuff. The server hello is more of the same, and usually includes the server's certificate. The server can now request the client cert, but this is the first time anyone asks anything. Once the server hello is sent, the client NOW checks the server cert before proceeding. In the draft spec, there is a good flowchart which I won't reproduce. Basically your ordering is a little screwy. > A. Servers' public key > Server could be using 512-bit, most likely 1024-bit > B. What algorithm to use to generate the session key > DES, IDEA, RC4, RC5 etc. Um, I'll be picky. These are ciphers (block, block, stream, block - in order), not (pseudo) random number generators. The first thing the client sends is a clump of random stuff. From this clump, MD5 and SHA are used with more random stuff to generate some more stuff. This stuff is used to generate stuff which is part of the final keys. [snip] > Browser then generates a random session key using a algorithm > that the web server supports. (hopefully the highest?) > Browser type/version is crucial to key generation. Well...the PRNG (pseudo random number generator) is presumably implementation dependant, yes. As far as I can see, though, the pre-master-secret is always 48 bytes including 2 bytes of version (to stop rollback atacks). If your PRNG sucks then there's less entropy in the pre-master-secret and your session key is weaker. > Browser then encrypts the random session key with the > server's public key and sends it to the web server. Assuming the most common (RSA w/ DES) SSL hookup and moduluo the fact that it's not really the key, yep. > 5. Web server receives it and uses it's secret key to decrypt > the transmission and extracts the random session key that was > generated by the browser. > 6. Web server then uses this random session key to encrypt > the data it sends to the browser. > 7. The browser also uses this random session key to encrypt > the data it sends to the web server. > I heard rumor that step 6 & 7 use a separate key? True, False? True. But the client does NOT generate the whole key, as I said before. Really vague overview is something like: Lightly beat 28 bytes of server.random and client.random, allow to cool. Buy a fresh 48 byte clump of random from a store near the client. Add salt (ick) to taste. Mix all secrets, place in three oven-ready bowls and allow to cool (uh, use SHA). Bake the three layers separately (or MD5 - whatever), layer and cover with icing. You now have a cake. This cake is called the Master Secret. Both the client and the server have a copy, and you can see that it uses ingredients from both. When we go to generate server.write and client.write keys, it's a bit like cutting up the cake. Except you're not allowed to take the cake home if there's any left. > My interpretation of some other concerns: > 1. Step 4 to me is security hole. If intercepted (see para 3 > below), the attacker must mimic the work that the research > team used to break a 512-bit RSA key. They would have to > attack a specific web server's 512-bit RSA secret key that > was generated on that particular web server. Once broken, the > attacker would then be able to derive the random session key > that was generated by the browser. Once obtained, as long as > the attacker continues to intercept the transmission that > encrypts the actual random session key, they would have > access to the data. This would continue until the web server > generated a new secret key. On most web servers, this is done > annually. Some re-generate it every time the server re-boots. > Once re-generated, the attacker would have to crack the new > 512-bit key. The SSL spec recommends 512 bit temp keys be replaced daily. If the RSA key remains secure, you have forward secrecy - cracking the eeny-weeny 40 bit DES key shows you this transaction, but it's no good for the one I'll make tomorrow. However, this is what _I_ consider to be the real security risk - it's much more likely, for a start. Sure it's only one transaction at a time, but someone with a moderate collection of resources can read 40 bit DES in realtime. (OK, so that's a lie. It takes a couple of seconds). Not that you'd care, because I guess your board and members are all in the US. If the RSA Public doover were factored, however, an attacker could just grab the new keys as they were generated, yes. And this would be bad, yes. > 2. The random session key is going to be different each time > the browser starts a session with a web server. Some web > servers will "expire" the random session key in the middle of > a session and force the browser to re-generate another random > session key. Uh, they shouldn't. But it could happen I guess. > 3. To intercept the transmission, is itself a major > undertaking. The attacker would have to either directly > connect some sort of recording device to a line that all of > the browser's data flows through, Which is "hard" but not that hard. There are usually SO SO SO many untrusted points in a long path that you should never assume the data is safe from a physical sniffer. > or make the browser believe > that a phony web server is the one it wants to talk to. Now _this_ is hard. That's why we have Certification Authorities, remember? I'll trust strong crypto over physically secured copper any day of the week. > Either way, my understanding is that it's very difficult to > intercept ALL data flowing to or from a particular browser to > derive the packets of data that contains the random session key. I wouldn't go as far as very difficult. Check out some of the whining the cable modem users are doing on bugtraq... > Thanks for the help, > Michael Sorbera > Webmaster of a Federal Credit Union > "In the land of the clueless, he who has half a clue is King!" I don't want to be mean, but READ THE SPEC! It's not even that hard to understand! Email me OOB and I'll give you a shipping address for my editing cheque. ;) Cheers, > </clueless off> -- Ben Nagy Network Consultant, CPM&S Group of Companies PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520 - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
