|
To all, First I’d like to thank everyone that participated in the previous threads. I appreciated you’re being patient, and explaining to me the err’s (many, many errors!) of my ways. I don’t always get it right the first time, but I don’t give up till I get it right! 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. <clueless on> Browser verifies the validity of the web servers’ digital certificate with Verisign or some other authenticating authority.
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. Different browser and versions have different algorithms they use. Some are strong, some not. Browser type/version is crucial to key generation. 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? 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. 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. 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, or make the browser believe that a phony web server is the one it wants to talk to. 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. </clueless off> 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!" |
