Hello Army RL, Sunday, October 24, 2004, 14:58:59, you wrote:
(snip) h>> But, here, we must draw the line. If the user succeeds in finding out h>> the missing intermediate roots, and adds them to the base, then h>> everything is OK, and life goes on. Otherwise -- i.e. there are still h>> missing intermediate roots --, then TB! *HAS* to refuse using the h>> certificate. If this is not an option for the user, then I humbly h>> suggest the user to stop using SSL (or other schema in the same line). AR> Here is where you lose me. You say it's ok to add the incomplete cert AR> to the base earlier then here you say TB! has to refuse using the AR> incomplete cert and even user, such as I, should stop using the AR> security/privacy afforded by an encrypted session to transport email to AR> and from the mail server? OK. Let me rephrase this. First of all you can add a rootless public certificate in the base. The expectation is that you will, eventually (and before actually using this certificate) add in the missing roots. Secondly, the security/privacy attained by the use of encryption is also dependent on guaranteeing the integrity of the certificate (and, by extension, of the public/private key pair it uses). On a production environment, the risks of using a rootless public certificate are unacceptable. The reason here is you cannot distinghish a 100% real-honest-I-swear-over-whichever-grave-you-want-me-to-use BUT rootless from a counterfeit, identical in the identification data, one. Encryption has many issues, but one of them, a very important one, is: *Key managament & distribution* This is the part of "using encryption" that worries about storing encryption keys, and safely distributing them. An encryption algorithm can be the best out there in the market but, if the key is compromised... it does not really matter if you are using encryption or not! TLS/SSL adresses the key M&D by using a public key algorithm. The TLS/SSL certificate is actually composed of two parts -- the private key, which is never distributed, and the public key. The public key is encapsulated in what is, by abuse of language, called the "certificate" and, more strictly, the public certificate. It's the public certificate that gets send over the wire when a TLS/SSL session is being negotiated. Now, TLS/SSL will negotiate one symmetric encryption key at every start of session (and, probably more during the session), by using the asymmetric keys (the private and public ones) to establish an ephemeral encrypted session. When the symmetric encryption key has been generated, the ephemeral session is ended, and both parties start using the newly-generated symmetric key. THIS is the key that is used to encrypt the session data -- in our case, to download/upload e-mails to the server. If you cannot safely confirm the public certificate, it follows that you cannot trust the resulting generated symmetric keys, and encrypted sessions using them. h>> When you receive a certificate (on SSL negotiation) you do NOT trust h>> this certificate. What you "trust", want it or not, is that it's h>> signature can be verified by a "known" authority -- known to you, and h>> accepted as such by you. This "known" authority is represented by the h>> root certificates you accepted to use. Your trust on the certificate h>> you received is transitive: you trust it because a know root confirms h>> it. And *THIS* root is trusted by you not to mess up. As such, if h>> there are missing intermediate root certificates, then there is no h>> trust transitivity, and the certificate you received is, by default, h>> tainted. AR> This is not *always* so. If I was concerned with the entire PKI or AR> hierarchy of it- then yes. If all I want to do is communicate via secure AR> transport with a mail service and can verify the "servers" cert, as well AR> other factors like the IP of the server, published info about the cert AR> on the website, etc then I can be satisfied. My personal standard has AR> been met in this case- and it may not always *require* having placed my AR> trust completely in the CA or Intermediaries. Why must I trust them AR> anyways? Please let me give you an example of an issue here. Let's say your mail server is at address 10.10.10.10, and it's fully qualified name is "mail.dummyserver.info". This means that you could query DNS on 10.10.10.10, and would get "mail.dummyserver.info" as a response, or query DNS on "mail.dummyserver.info", and get an IP address of 10.10.10.10. So far, so good. Now, in comes a bad guy. This bad guy can: (a) poison the DNS to re-route all your sessions requests to a different server; (b) physically cut the wire and insert his system in between you and your connection, or between your mail server and your connection. In both ways, it is easy to set up things such as the bad guy has a session to your mail server (using the real mailserver certificate), and another session to you, using a fake mailserver certificate (for which, guess what: no root is available...). So,you go get your mails, and it's the bad guy that answers you. All mails you send up/downaload are received by the bad guy (in clear text) and immediately uploaded to the mail server/downloaded to you. This is possible because the bad guy is posing as YOU, with your account, password, lock, stock, and all barrels)! After all, YOU sent him your account, password, SecureId, whatever... Also, I fail to understand a site that publishes it's public certificate, but does not provide pointers to the roots (i.e., to where you can get the roots, and it better be a completely different place!). AR> My trust is in the server. The certificate is there to afford me the AR> opportunity to establish the security and privacy provided by an AR> encrypted transport with this trusted server... As shown above, you cannot trust your "server". And... you cannot trust a rootless certificate. You can swallow it, but not trust. AR> Nothing can force me to trust the entire chain in a formal PKI and AR> certainly shouldn't be a forced requirement when my trust is established AR> in the server only, in some cases. No. nothing can force you to. The whole idea of root certificates on TLS/SSL is to allow you to *confirm* that a public certificate received has been verified by someone. And... this someone survives only because he will never, ever, sign a fake certificate. Yeah, yeah, I know, iffy. See below for a failure :-). The idea here is similar to the web of trust in PGP/GNUPG. You do not know me, but you know someone that signed my PGP key stating I am who I say I am. You do not actually, really, know your server's certificate, or any other certificate you receive when opening a TLS/SSL session, but... down the line, there's a root certificate you decided to trust. This is why I said that trust is transitive. But... you are correct: why should we trust a CA? AR> As you mention below, self signed certs will always be a factor. Simply AR> due to the cost associated with the mainstream CA's, especially with AR> those roots included in OS and browsers. Once my standards heve been AR> met then I should be the decision maker, imnsho, not TB!. OK. OK. I accept it. The *final* user should have a *final* say on whether the rootless certificate will be accepted or not. On further thinking, I consider your approach valid, albeit the result is a potentially compromised session. But, the user assumes all risks. Caveat emptor. h>> This is not paranoia (although, I have to say, I *am* paranoid). This h>> is simply the rules of the game. AR> I am interested in where you have read these "rules of the game", AR> falling under the broad umbrella of paranoid myself. See (for start) ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt, which is the TLS RFC. At page 39 it states: " certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. * my markings here - hggdh * *Because certificate validation REQUIRES that root keys be distributed independently*, * my markings here -hggdh * the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case." And, then, the rest of RFCs, and the PKIX IETF work group. (snip) h>> Allie, you are absolutely correct when you wonder about the security h>> of this. There is none. AR> I beg to differ. The user, regardless of what any one entity says, is AR> the *final* approving authority on what is acceptable in regards to what AR> level of security and privacy that user desires. Which does not change my point above. There is no gained security. At all. But this is a risk that YOU, as the final user, has to have the rigth to accept. AR> There is no security afforded, whatsoever, when TB! refuses to allow me AR> to even view an incomplete certificate chain. All I am permitted to do AR> is say OK or Cancel... TB! is being strict here. I personally like this. But, as I said above, I now do agree with you (in that the final user has to have the final say, even if this means throwing out all theoretical security and privacy). (snip) AR> Thanks for the feedback, looking forward to more- and hopefully AR> (eventually) even get entertained by the development powers that be. Indeed, this is fun. I suggest you to open a formal wish (I do not know how to do it, but certainly someone in here will). I will sign down on it (given that a stern warning is issued prior to acceptance of the rootless public certificate). On using a hash, or equivalent, to verify if the newly received certificate is identical to one stored: this is already available. All TLS/SSL public certificates have such a hash. So, what would be needed is to warn the user that the just-received certificate does *NOT* match the one stored. Now for a short story: some years ago a major CA issued some certificates to Microsoft. So far, so good, they had issued other certificates to Microsoft. The problem... it was NOT Microsoft that requested it :-)! Oh boy... -- ..hggdh.. Using The Bat! v3.0.1.33 and BayesIt! 0.7.3 on Windows 2000 5.0 Build 2195 Service Pack 4
pgp4QiZn8sY5k.pgp
Description: PGP signature
________________________________________________________ Current beta is 3.0.2.1 Beta/1 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
