Hello hggdh, Sunday, October 24, 2004, 5:46:31 PM, you wrote:
h> Hello Army RL, h> Sunday, October 24, 2004, 14:58:59, you wrote: h> (snip) h> OK. Let me rephrase this. First of all you can add a rootless public h> certificate in the base. The expectation is that you will, eventually h> (and before actually using this certificate) add in the missing roots. The only reason I would/should need to add any certificate to the base is because I am concerned with authentication, ensuring what I have on file is what is presented to me each time I reinitiate comms with the server. I don't necessarily need that with a particular server, I simply want an encrypted channel for transporting my mail securely (hence privately:) from me to them. I use PGP for true message security and privacy anyways- especially since the storage of the message until retrieved by the recipient and how that user retrieves it may make all my transport prerequisites null and void anyways. back to your point- doing this, adding the rootless public to the base does nothing- the popup remains the same- with the same unselectable buttons- user is still forced to just OK or Cancel it... h> Secondly, the security/privacy attained by the use of encryption is h> also dependent on guaranteeing the integrity of the certificate (and, h> by extension, of the public/private key pair it uses). not quite- you mix potatoes with tomatoes here... ;) althoughy all closely related I do admit, and in most settings all *should* be considered for perfection. but please correct me if I am wrong... Security, Privacy, and Authentication, while they are all very desirable together they *are* three separate functions as well they are all very familiar to those of us who use PGP, GPG, and dabble a bit in PKI/x509's (our dreaded certificate conversation again;) Security is at my box and at the server. When the server and client establish an encrypted transport, privacy is afforded enroute. this message is also secure from tampering... authentication, on the other hand (hence the potato/tomato line) is *very* nice almost to the point of "should be" required, however it is not a requirement- nor a standard as you will see from the quote I provide in response to your text below. h> If you cannot safely confirm the public certificate, it follows that h> you cannot trust the resulting generated symmetric keys, and encrypted h> sessions using them. not so, at least in my case- I trust the algo and other details of the encrypted session- the only worry I would have is in knowing exactly *who* I have set up a session with. Once my personal requierments have been met- then all should be good... for me, the user... (errrm, not 1_user either;) 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. <sigh> I understand- and agree... *If* I want that handshake to provide me proof of who it is I establish the session with... *If* I desire authentication, then yes- waht you have said above and most folks are saying is true. But, this particular user doesn't require authentication in this circumstance- call it sacriledge- but I don't. and by the RFC's and FAQs I can find on the matter it doesn't say this is required- only that the session must fail if authenticating the entity thru their session based certificate is requested. again, I simply want TB! to give me that option- if I don't want to authenticate, perhaps, thengive me plenty of warnings- but let me permanently accept that particular cert for future sessions- not force me to amnually OK it each time I connect to the server(s) in question.... (power to the people!! ;) 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? h> Please let me give you an example of an issue here. Let's say your h> mail server is at address 10.10.10.10, and it's fully qualified name h> is "mail.dummyserver.info". This means that you could query DNS on h> 10.10.10.10, and would get "mail.dummyserver.info" as a response, or h> query DNS on "mail.dummyserver.info", and get an IP address of h> 10.10.10.10. h> So far, so good. h> Now, in comes a bad guy. This bad guy can: (a) poison the DNS to h> re-route all your sessions requests to a different server; (b) h> physically cut the wire and insert his system in between you and your h> connection, or between your mail server and your connection. <snip> good thing I have (firewall) resricted my client to only connect to certain ports and certain IPs... as well, I use a local, windows version of BIND- called BindPE- it caches locally and only updates from the root DNS servers- mighty big poison job to effect anything there. regardless- I doubt my chocolate chip cookie recipes are valuable enough for some organization to go through all that trouble to MitM me... h> Also, I fail to understand a site that publishes it's public h> certificate, but does not provide pointers to the roots (i.e., to h> where you can get the roots, and it better be a completely different h> place!). One huge org, the US Army (possibly other DoD/mil as well:) and one excellent privacy resource, Cotse. Neither one are amatuers nor haphazard. nor very responsive at times.... :( 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... h> As shown above, you cannot trust your "server". And... you cannot h> trust a rootless certificate. You can swallow it, but not trust. but I *can* trust my/these server(s)- if and when they meet *my* criteria for that trust at the level I need/require/desire at the time... (man I sing the same song alot, eh?:) 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. h> No. nothing can force you to. The whole idea of root certificates on h> TLS/SSL is to allow you to *confirm* that a public certificate h> received has been verified by someone. And... this someone survives h> only because he will never, ever, sign a fake certificate. Yeah, yeah, h> I know, iffy. See below for a failure :-). The whole idea is to "Authenticate" and it is not a required function of establishing encrypted transport. h> But... you are correct: why should we trust a CA? exactly- especuially if/when all I want is encrypted transport... <BG> 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!. h> OK. OK. I accept it. The *final* user should have a *final* say on h> whether the rootless certificate will be accepted or not. On further h> thinking, I consider your approach valid, albeit the result is a h> potentially compromised session. I agree and Thank you! h> But, the user assumes all risks. Caveat emptor. amen!! warn me once, allow me to import permanently, check fingerprint from then on but don't pop up fail the encrypted transport I am trying to establish without a monitored OK button push... for those that are not sure or don't feel right- they can always *not* import the incomplete cert... 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. h> See (for start) ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt, which h> is the TLS RFC. h> At page 39 it states: h> " certificate_list h> This is a sequence (chain) of X.509v3 certificates. The sender's h> certificate must come first in the list. Each following h> certificate must directly certify the one preceding it. h> * my markings here - hggdh * h> *Because certificate validation REQUIRES that root keys be h> distributed independently*, h> * my markings here -hggdh * h> the self-signed certificate which specifies the h> root certificate authority may optionally be omitted from the h> chain, under the assumption that the remote end must already h> possess it in order to validate it in any case." h> And, then, the rest of RFCs, and the PKIX IETF work group. and in my defense I submit the following, from the same RFC (which, btw, is not a "Standard", only a proposal to be considered- and, uh, commented on;) I've tossed in some more supporting documentation as well- like the old SSL3 RFC and the official FAQ... etc. for this first part, please focus on the usage of optional, may, should... besides pg 7.3 appendix f.1.1 and f.1.1.1 are *very* clear- in their support of anonymous, nonauthenticating method of using TLS to establish a secure/private encyrpted channel... it is sternly warning of the potential attack- but perhaps an anon is willing to accept that compromise... anyways- I pasted a lot of it here- and will probably get yelled at, but it is clear to me and my request is *very* reasonable... <g> =========== From RFC 2246 7.3. Handshake Protocol overview The cryptographic parameters of the session state are produced by the TLS Handshake Protocol, which operates on top of the TLS Record Layer. When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, ***optionally authenticate each other,*** and use public-key encryption techniques to generate shared secrets. Cipher Spec. At this point, the handshake is complete and the client and server may begin to exchange application layer data. (See flow chart below.) Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Fig. 1 - Message flow for a full handshake >>>> * Indicates optional or situation-dependent messages that are not always sent. <snip> F. Security analysis The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel. This appendix outlines how TLS has been designed to resist a variety of attacks. F.1. Handshake protocol The handshake protocol is responsible for selecting a CipherSpec and generating a Master Secret, which together comprise the primary cryptographic parameters associated with a secure session. The handshake protocol can also optionally authenticate parties who have certificates signed by a trusted certificate authority. F.1.1. Authentication and key exchange TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked. The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the certificate verify and finished messages, encryption keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished message, parties thus prove that they know the correct pre_master_secret. F.1.1.1. Anonymous key exchange Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret. (Note that no anonymous RSA Cipher Suites are defined in this document). With Diffie-Hellman, the server's public parameters are contained in the server key exchange message and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e. the pre_master_secret). **** Warning: Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper- proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern. <snip> ****[later in the appendix, under DH exchange] Following the hello messages, the server will send its certificate, if it is to be authenticated. === From the SSL-Talk-FAQ SSL3 over SSL2 Functionality improvements: 2. SSL 3.0 allows the server and client to send chains of certificates. This allows organizations to use a certificate hierarchy that is more than two certifications deep. === SSL vs3- http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#7-5 7.6.2 Server certificate If the server is to be authenticated (which is generally the case), the server sends its certificate immediately following the server hello message. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509.v3 certificate (or a modified X.509 certificate in the case of Fortezza [FOR]). The same message type will be used for the client's response to a server certificate request message. =========== I actually found a lot more- but in the interest of the innocent bystanding readers and the strong arm of the law round these parts I omit them (besides, some of this can really lull folks to sleep!;) 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. h> Which does not change my point above. There is no gained security. At h> all. But this is a risk that YOU, as the final user, has to have the h> rigth to accept. ahhh- but there is both security and privacy- just no authentication... which may very well be a required part of *your* and half the planet's security definition- but I would still like to make my own decisions here... am I compromising- sure and it pisses me off that these two- and many more I'm sure don't follow the RFC and add that integral component, authentication... but I desire the encrypted channel, with a bit of non-annoying convenience of having to push the same button every single session... they aren't changing anything and I will compromise to have what I can get- encryption... with a potnetial gamble that I am not valuable enough a target for MitM- hell if they want my cookie recipe that bad- they could give me half that money and have them!! <BBG> 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... h> TB! is being strict here. I personally like this. But, as I said h> above, I now do agree with you (in that the final user has to have h> the final say, even if this means throwing out all theoretical h> security and privacy). heh, see same line above- but thanks for agreeing, however reluctantly! AR>> Thanks for the feedback, looking forward to more- and hopefully AR>> (eventually) even get entertained by the development powers that be. h> Indeed, this is fun. I suggest you to open a formal wish (I do not h> know how to do it, but certainly someone in here will). actually I thought my first post on the matter was the formal wish...? I will call it a "Feature Request" tomorrow then <g> h> I will sign down on it (given that a stern warning is issued prior to h> acceptance of the rootless public certificate). Thank you, I will draft something up less whingy and more formal looking before leaving for the weekend. Hopefully the subject will receive comment from the developers... eventually... h> On using a hash, or equivalent, to verify if the newly received h> certificate is identical to one stored: this is already available. All h> TLS/SSL public certificates have such a hash. So, what would be needed h> is to warn the user that the just-received certificate does *NOT* h> match the one stored. Yes! then a screaming warning! and of course, alow the user to per session or permanently accept this new cert! LOL h> Now for a short story: some years ago a major CA issued some h> certificates to Microsoft. So far, so good, they had issued other h> certificates to Microsoft. The problem... it was NOT Microsoft that h> requested it :-)! Oh boy... I recall that well- twas some scrambling over that! -- Most Sincerely, Mark (Army RedLeg) Enjoying TheBat! Professional Edition v.3.0.2.1 on Win2kSP4/PIII-600/512MB. coming to you "LIVE!, From Albuquerque" <g> Eric Howes' Protecting Your Privacy & Security: https://netfiles.uiuc.edu/ehowes/www/ Good chance you'll find *all* the goodies here: http://lists.gpick.com/ looking for a nice place off the beaten usenet path? join us: nntp://news.securecomp.org ________________________________________________________ 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/
