Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello TheBat! Beta Testers and Developers! Not a popular subject I take it, as it dies fairly quickly without being entertained as a valid issue. While I consider it a bug- or at least annoying at a minimum, I figure with a subject of "Feature wish" it my get some actual consideration over me beating that 'dead horse' again... Issue- Initiate SSL or TLS session with POP/IMAP/SMTP server that presents an Incomplete certificate chain (has verifiable server certificate but lacks CA or issuer in the chain). Discussion- Whenever the POP/IMAP/SMTP server fails to provide the root/CA certificate or full chain with the server certificate TB! pops up an "Unknown CA certificate" warning. In this warning dialog box is a few buttons with "OK" and "CANCEL" always selectable, giving temporary/session permission, but "View Certificate" and "Add to Trusted" are not selectable unless the server provides a full certificate chain. Not being able to view and or add to trusted forces the user to manually OK the session each and every time a connection is made to these servers. On accounts where this is true and automatic checking for new mail is set this dialog box can be hidden behind other windows and even hang the client and/or system if not answered in a timely fashion. If TB! is minimized to systray and the connection center is minimized to toolbar the only way to view the "Unknown CA Cert" dialog box to OK or Cancel is to right click on TB! in the system tray- bringing the focus of the "UKN CA" dialog to the front. I have had to set 4 different accounts with two servers to manual checking for new mail only due to this behavior. Strange thing is with one of these servers I already have the CA cert in my address book- it is there from the SMTP chain with this service (cotse.net). The other service (us.army.mil) remains unresponsive in my requests they negotiate POP/IMAP/SMTP sessions with a complete certificate chain- and doubt there will be many voices raising issue with this as other clients deal with it very easily. Recommendation- The "Unknown CA Certificate" dialog box must give the User the ability to always select "View" allowing for a verification of server cert presented. When viewing certificates in this manner a "hash" or digital fingerprint should be made of the certificate that TB! will check against in all future sessions to protect against sudden changes, tampering, MitM issues, etc... The "Unknown CA Certificate" dialog box should give the User the ability to "Add to Trusted" any server certificate, chain complete or not, if they have viewed/verified and have determined this is from a server the User trusts (again, regardless if the server negotiates with a complete chain or not). In closing- I would appreciate hearing other users input on this as well if it is a valid feature wish and whether it is considered from the Development team. Thank you. -- 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" 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
On Saturday, October 23, 2004 at 1:34:00 PM [GMT -0500], Army Redleg wrote: > Not a popular subject I take it, as it dies fairly quickly without > being entertained as a valid issue. Perhaps because not many have this problem. I'd normally not be too inclined to discuss a problem that doesn't affec me, but in this case I'll offer an opinion. :) I do use SSL/TLS, but I don't have the problem you're having since I do get offered all the certificate info/parts. > While I consider it a bug- or at least annoying at a minimum, I figure > with a subject of "Feature wish" it my get some actual consideration > over me beating that 'dead horse' again... Not to worry. You'll not be admonished for bringing this up more than once. However, the technically oriented members here tend to be sensitive about TB! being accused of buggy behaviour when it simply fails to cater to non-standard behaviour by servers. It doesn't really have to do this. It's the server admins who really aught to get their act together. However, I'm pragmatic on issues as these and understand that in the end, it's the users comfort and not standards conformation battles that do matter at the very end. I do realize that conformation to standards and user comfort do go hand in hand, so the clients and servers really aught to remain compliant. Providing workarounds is a really sensitive issue. Though it makes the user less frustrated in the end, one wonders what it will do to those who keep breaching the agreed on standards and getting away with it. They'll breach it again, and again, and again. Should this be allowed for security standards, especially when the breach is clearly not in the spirit of good security? > Discussion- > Whenever the POP/IMAP/SMTP server fails to provide the root/CA > certificate or full chain with the server certificate TB! pops up an > "Unknown CA certificate" warning. Shouldn't it? > In this warning dialog box is a few buttons with "OK" and "CANCEL" > always selectable, giving temporary/session permission, but "View > Certificate" and "Add to Trusted" are not selectable unless the server > provides a full certificate chain. Well, the certificate cannot be viewed without all the information. How can it be trusted without the full cert chain? So these are greyed out. > Not being able to view and or add to trusted forces the user to > manually OK the session each and every time a connection is made to > these servers. On accounts where this is true and automatic checking > for new mail is set this dialog box can be hidden behind other windows > and even hang the client and/or system if not answered in a timely > fashion. So you're wishing for a trust anyway button? :) > Recommendation- > The "Unknown CA Certificate" dialog box must give the User the ability > to always select "View" allowing for a verification of server cert > presented. > When viewing certificates in this manner a "hash" or digital fingerprint > should be made of the certificate that TB! will check against in all > future sessions to protect against sudden changes, tampering, MitM > issues, etc... > The "Unknown CA Certificate" dialog box should give the User the ability > to "Add to Trusted" any server certificate, chain complete or not, if > they have viewed/verified and have determined this is from a server the > User trusts (again, regardless if the server negotiates with a complete > chain or not). > Interesting. Seems reasonable, though one wonders about the security of it. I guess you're more interested in transmission encryption more than strict authentication of the certificates? -- -= Allie =- . Using yesterday's technology to solve today's problems, tomorrow __ IMAP [ Client: The Bat! v3.0.1.33 | Server: MDaemon Pro ] OS: Windows XP Pro (Service Pack 2) 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello Allie, Saturday, October 23, 2004, 17:36:00, you wrote: AM> On Saturday, October 23, 2004 at 1:34:00 PM [GMT -0500], Army Redleg AM> wrote: >> Recommendation- >> The "Unknown CA Certificate" dialog box must give the User the ability >> to always select "View" allowing for a verification of server cert >> presented. Agree. See below. >> When viewing certificates in this manner a "hash" or digital fingerprint >> should be made of the certificate that TB! will check against in all >> future sessions to protect against sudden changes, tampering, MitM >> issues, etc... Disagree. Se below. >> The "Unknown CA Certificate" dialog box should give the User the ability >> to "Add to Trusted" any server certificate, chain complete or not, if >> they have viewed/verified and have determined this is from a server the >> User trusts (again, regardless if the server negotiates with a complete >> chain or not). >> Agree. See below. AM> Interesting. Seems reasonable, though one wonders about the security of AM> it. I guess you're more interested in transmission encryption more than AM> strict authentication of the certificates? An user should *always* be allowed to "View" a certificate, mostly when there is an issue regarding it's validity (like an incomplete root chain). If this does not happen nowadays, then it is a bug on TB!. No questions about it. One might even go ahead and allow the user to add a certificate with an incomplete root chain to the base. No big deal here. But, here, we must draw the line. If the user succeeds in finding out the missing intermediate roots, and adds them to the base, then everything is OK, and life goes on. Otherwise -- i.e. there are still missing intermediate roots --, then TB! *HAS* to refuse using the certificate. If this is not an option for the user, then I humbly suggest the user to stop using SSL (or other schema in the same line). When you receive a certificate (on SSL negotiation) you do NOT trust this certificate. What you "trust", want it or not, is that it's signature can be verified by a "known" authority -- known to you, and accepted as such by you. This "known" authority is represented by the root certificates you accepted to use. Your trust on the certificate you received is transitive: you trust it because a know root confirms it. And *THIS* root is trusted by you not to mess up. As such, if there are missing intermediate root certificates, then there is no trust transitivity, and the certificate you received is, by default, tainted. This is not paranoia (although, I have to say, I *am* paranoid). This is simply the rules of the game. Allie, you are absolutely correct when you wonder about the security of this. There is none. Another option here is that this server is using a self-signed certificate. If this is the case, all that is needed to do is add the certificate itself to the trsuted root. 0bviously, there is then the problem of trust, back to haunt: you *can* trust a self-signed certificate, as long as you can positively confirm it. Since you cannot use a trusted root anymore, the only way to confirm it is by direct contact with the other party. Only after such confirmation should you add the certificate to the trusted root. -- ..hggdh.. Using The Bat! v3.0.1.33 and BayesIt! 0.7.3 on Windows 2000 5.0 Build 2195 Service Pack 4 pgpfiUhEmR5oV.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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello hggdh, Saturday, October 23, 2004, 6:16:44 PM, you wrote: h> An user should *always* be allowed to "View" a certificate, mostly h> when there is an issue regarding it's validity (like an incomplete h> root chain). If this does not happen nowadays, then it is a bug on TB!. h> No questions about it. absolutely, if it can not be viewed we will never know the details of what was used to establish the SSL/TLS session and whether it should be trusted in the first place. h> One might even go ahead and allow the user to add a certificate with h> an incomplete root chain to the base. No big deal here. Which is what I have done, but it makes no matter as each session/connection must be manually approved still. 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). Here is where you lose me. You say it's ok to add the incomplete cert to the base earlier then here you say TB! has to refuse using the incomplete cert and even user, such as I, should stop using the security/privacy afforded by an encrypted session to transport email to and from the mail server? 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. This is not *always* so. If I was concerned with the entire PKI or hierarchy of it- then yes. If all I want to do is communicate via secure transport with a mail service and can verify the "servers" cert, as well other factors like the IP of the server, published info about the cert on the website, etc then I can be satisfied. My personal standard has been met in this case- and it may not always *require* having placed my trust completely in the CA or Intermediaries. Why must I trust them anyways? My trust is in the server. The certificate is there to afford me the opportunity to establish the security and privacy provided by an encrypted transport with this trusted server... Nothing can force me to trust the entire chain in a formal PKI and certainly shouldn't be a forced requirement when my trust is established in the server only, in some cases. As you mention below, self signed certs will always be a factor. Simply due to the cost associated with the mainstream CA's, especially with those roots included in OS and browsers. Once my standards heve been met then I should be the decision maker, imnsho, not TB!. h> This is not paranoia (although, I have to say, I *am* paranoid). This h> is simply the rules of the game. I am interested in where you have read these "rules of the game", falling under the broad umbrella of paranoid myself. RFC, FAQ, Internet Draft, Protocol Specification, Standard, other? h> Allie, you are absolutely correct when you wonder about the security h> of this. There is none. I beg to differ. The user, regardless of what any one entity says, is the *final* approving authority on what is acceptable in regards to what level of security and privacy that user desires. There is no security afforded, whatsoever, when TB! refuses to allow me to even view an incomplete certificate chain. All I am permitted to do is say OK or Cancel... I further feel this is a *very* reasonable request, to the point of being a no-brainer- when it comes to giving the user the decision making authority and allowing the user to satisfy his/her own security and/or privacy standards- rather than have them dictated and forced. h> Another option here is that this server is using a self-signed h> certificate. If this is the case, all that is needed to do is add the h> certificate itself to the trsuted root. 0bviously, there is then the h> problem of trust, back to haunt: you *can* trust a self-signed h> certificate, as long as you can positively confirm it. Since you h> cannot use a trusted root anymore, the only way to confirm it is by h> direct contact with the other party. Only after such confirmation h> should you add the certificate to the trusted root. Agreed! TB! allows for no user decision here, which falls back on it doesn't matter if it is a self signed job or not... Simply allow the user to decide when their personal trust standard
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello Redleg, Sunday, October 24, 2004, 8:09:21 PM, you wrote: AR> Hello Allie, >>> Discussion- >>> Whenever the POP/IMAP/SMTP server fails to provide the root/CA >>> certificate or full chain with the server certificate TB! pops up an >>> "Unknown CA certificate" warning. AM>> Shouldn't it? AR> Yes it should. However, I would further desire TB! allowing the user to AR> hash/fingerprint the accepted cert for more than one session, if the AR> user so desires, and not have to manually OK this action each time. Indeed! I support this because I can use other methods to establish trust separate to the certificate. What I need TB! to do is tell me that a certificate is identical to the one I trusted yesterday. AR> Does that really make any sense at all? TB! allows me to start a SSL or AR> TLS session with an unverified certificate? >>> Not being able to view and or add to trusted forces the user to >>> manually OK the session each and every time a connection is made to >>> these servers. On accounts where this is true and automatic checking >>> for new mail is set this dialog box can be hidden behind other windows >>> and even hang the client and/or system if not answered in a timely >>> fashion. AM>> So you're wishing for a trust anyway button? :) AR> YES!! AR> well, sorta- hitting OK is the "trust anyway" button. Allowing me to AR> import what I want to import to my trusted certs is the "Trust Anyway" AR> button I seek! Yes exactly! When I contact my brother, I have an encrypted connection that can be used as a conduit to exchange pointers to jointly known silent secrets. Or in an extreme a voice p2p call will verify the contents of an incoming mail so that in future the non-rooted certificate can be trusted for future correspondence. AM>> Interesting. Seems reasonable, though one wonders about the security of AM>> it. I guess you're more interested in transmission encryption more than AM>> strict authentication of the certificates? Quite right. My https: BBS uses a certificate signed only by the provider of my server software. Users are very happy to add my certificate without a CA root because they know they need encryption perhaps against a suspect ISP and having established trust (via a well known trusted server company) they need to know that in future when my IP changes that they are still talking to the same BBS. I understand the issues put forward in these mailinglists for only trusting CA rooted certificates, and challenge that when I use my work company's CA rooted certificate that this same certificate is used by a great number of people. Then contrast to me contacting a friend at home on a fixed IP DSL line with a non-rooted cert, which is more trustworthy in knowing the security of the delivered message ? Lastly can someone please tell me does TB! use certificates during 'chat' sessions ? I'd have thought that most users would not have traditional full certificates. Please support the 'Trust this certificate' change in TB! by keeping controls in place to protect the casual user as in the past and continue to flag immediately any certs not installed as trusted. James 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
On Sunday, October 24, 2004 at 2:09:21 PM [GMT -0500], Army Redleg wrote: > Hello Allie, > Saturday, October 23, 2004, 4:36:00 PM, you wrote: AM>> Not to worry. You'll not be admonished for bringing this up more than AM>> once. > this is good :) AM>> However, the technically oriented members here tend to be sensitive AM>> about TB! being accused of buggy behaviour when it simply fails to AM>> cater to non-standard behaviour by servers. > Understood, *if* these servers are indeed in violation of the > "Standard"... > Which now begs the question, after searching through various FAQs, > standards and proposals (IETF, ANS.1, ISO, etc)- I simply ended up with > a headache- swimming eyes and reeling mind... > If you know where I can find this standard (will/must versus > may/should), please point me in the general direction. AM>> It doesn't really have to do this. It's the server admins who really AM>> aught to get their act together. However, I'm pragmatic on issues as AM>> these and understand that in the end, it's the users comfort and not AM>> standards conformation battles that do matter at the very end. I do AM>> realize that conformation to standards and user comfort do go hand AM>> in hand, so the clients and servers really aught to remain AM>> compliant. > Although I feel TB! is the best client on the planet- and certainly the > most flexible and powerful in configuration, I fail to see why it > refuses to allow the user to make the choice in this circumstance. *If* > these servers are in direct violation of published standards then I will > humbly agree with everything folks say about killing my 'feature wish' > and start begging the US Army/military and Cotse to get their act > together and get in compliance with a referenced published standards and > requirements... > (but I will always hold out on TB! giving the User the power of choice > in any email matter;) > perhaps I just want TB! to sell me the gun and ammo- allow me to pull > the trigger when I want to. AM>> Providing workarounds is a really sensitive issue. Though it makes the AM>> user less frustrated in the end, one wonders what it will do to those AM>> who keep breaching the agreed on standards and getting away with it. AM>> They'll breach it again, and again, and again. Should this be allowed AM>> for security standards, especially when the breach is clearly not in the AM>> spirit of good security? > I would probably not bother this good group again if I could start > arguing with those server admins on how they are breaching standards. > But would argue your point here where you say it is not in the 'spirit > of good security'. Spirit, perhaps the intent of the law- vice the > letter of the law, is what my feature wish really is (if indeed these > servers are in direct violation of the standard). > If the standard says may or should- well then there is no real violation > rather only a hardline approach to strict protocols that TB! refuses to > permit any deviation from. > If the standard does say will or must, then it is back to simply a > feature wish by a lazy user who desires security and privacy afforded by > this protocol with servers he/she trusts to transport his/her mail to > and from the server. >>> Discussion- >>> Whenever the POP/IMAP/SMTP server fails to provide the root/CA >>> certificate or full chain with the server certificate TB! pops up an >>> "Unknown CA certificate" warning. AM>> Shouldn't it? > Yes it should. However, I would further desire TB! allowing the user to > hash/fingerprint the accepted cert for more than one session, if the > user so desires, and not have to manually OK this action each time. >>> In this warning dialog box is a few buttons with "OK" and "CANCEL" >>> always selectable, giving temporary/session permission, but "View >>> Certificate" and "Add to Trusted" are not selectable unless the server >>> provides a full certificate chain. AM>> Well, the certificate cannot be viewed without all the information. How AM>> can it be trusted without the full cert chain? So these are greyed out. > Not true. A certificate should always be viewable how else can I even > begin to know what TB! is warning me about in the first place? I cannot > verify anything- simply know that TB! doesn't like something- not sure > what it is, but that I should trust TB! on making the choice for me and > allow me to initiate a single connection- again with encryption > established with an unverifiable certificate. > Does that really make any sense at all? TB! allows me to start a SSL or > TLS session with an unverified certificate? >>> Not being able to view and or add to trusted forces the user to >>> manually OK the session each and every time a connection is made to >>> these servers. On accounts where this is true and automatic checking >>> for new mail is set this dialog box can be hidden behind other windows >>> and even hang the client and/or system if not answered in a timely >>> fashion
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
On Sunday, October 24, 2004 at 2:09:21 PM [GMT -0500], Army Redleg wrote: AM>> However, the technically oriented members here tend to be sensitive AM>> about TB! being accused of buggy behaviour when it simply fails to AM>> cater to non-standard behaviour by servers. > Understood, *if* these servers are indeed in violation of the > "Standard"... Yes. This is the question for which I don't have an answer. Unless we know the answer, we cannot really make a strong claim either way. > Which now begs the question, after searching through various FAQs, > standards and proposals (IETF, ANS.1, ISO, etc)- I simply ended up with > a headache- swimming eyes and reeling mind... I know how you feel. I've tried looking up technical information like that and rarely come up feeling enlightened. I usually feel exhausted and frustrated. > If you know where I can find this standard (will/must versus > may/should), please point me in the general direction. I can't. :) This is why I didn't want to put a foot in too deep. > Although I feel TB! is the best client on the planet- and certainly > the most flexible and powerful in configuration, I fail to see why it > refuses to allow the user to make the choice in this circumstance. > *If* these servers are in direct violation of published standards then > I will humbly agree with everything folks say about killing my > 'feature wish' and start begging the US Army/military and Cotse to get > their act together and get in compliance with a referenced published > standards and requirements... Ok. > (but I will always hold out on TB! giving the User the power of choice > in any email matter;) Yes. I can agree with that, especially provided that standards compliance remains from the client side. > perhaps I just want TB! to sell me the gun and ammo- allow me to pull > the trigger when I want to. Yes. Security software generally does this. The good ones will provide you with all means of disabling various components and loosening security measures to fit your situation. However, GnuPG has some inflexible quirks as well. For example, you can't encrypt to a key that you haven't assigned some degree of trust to. I squawk at such a restriction personally and usually get purist responses. I do understand where you're coming from. :) This is one of the reasons why I prefer using PGP which enforces no such restriction. > I would probably not bother this good group again if I could start > arguing with those server admins on how they are breaching standards. > But would argue your point here where you say it is not in the 'spirit > of good security'. I meant it only in so far as the current standards being formulated from a position on security and what makes good security. One's position or the position of a panel of experts must come from a common spirit. Standards do change as borne by this spirit. Or it may offer flexibility as well. > If the standard does say will or must, then it is back to simply a > feature wish by a lazy user who desires security and privacy afforded > by this protocol with servers he/she trusts to transport his/her mail > to and from the server. Okay. > Let me worry about what is the definition of 'strict authentication of > the certificate'. Even if issued by Thawte, Comodo, US Army, etc. > there is nothing telling *me* that *I* must trust these issued certs > anyways- it will always be my decision. I just want TB! to allow me > to make that decision on a permanent basis, if/when I feel my own > standards have been met. I lean towards agreeing with this. The software really should just warn you and that's it. You then have the power to go ahead despite the warning. If it allows you one check, then it should allow checking all the time. :) -- -= Allie =- . Oxymoron: Science Fiction. __ IMAP [ Client: The Bat! v3.0.1.33 | Server: MDaemon Pro ] OS: Windows XP Pro (Service Pack 2) 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
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 cer
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello hggdh, Monday, October 25, 2004, 12:46:31 AM, you wrote: 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). Agreed, however integrity also must include physical security, in this context a CA is irrelevant. A past employer MD had his CA cert in a dummy name on his own locked private directline server in his office, you would need private trust that using the server implied that even his PA had no access. If I send Redleg a post at work dozens of people may have access to the message - via CA cert. Then I send to his home fixed IP, I only need worry about his family or his laxness in preventing them getting to his mail - self cert and fingerprint. In practice I am happy to trust the IP, but encryption gives us privacy. h> On a production environment, the risks of using a rootless public h> certificate are unacceptable. The reason here is you cannot distinghish h> a 100% real-honest-I-swear-over-whichever-grave-you-want-me-to-use BUT h> rootless from a counterfeit, identical in the identification data, one. Right, if you rely on the cert alone. Other methods can be used to validate a cert, as per my earlier post - provided that you can safely check fingerprint the cert every use. What I am asking for is notionaly the same as two PGP users each self signing their own key and not each others in a private web of two. h> Encryption has many issues, but one of them, a very important one, is: h> *Key managament & distribution* This is the part of "using h> encryption" that worries about storing encryption keys, and h> safely distributing them. This is not an issue when people already know each other. 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. I request the option to be the "known" authority myself and do the external validation myself. 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? OK, this is what I mean also but I've been more verbose! 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!). A spammer/bad guy connects to my private server and can get my name/company or other private details from the cert. 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. I disagree, I control my local server and DNS, Redleg controls his local server and DNS. We could happily exchange messages in clear but for privacy would like the option to choose to validate each others certs by external methods. h> The whole idea of root certificates on TLS/SSL is to allow you to h> *confirm* that a public certificate received has been verified by h> someone. For private use, personal private verification works fine. Browsers happily let you import a non-CA cert and allow a user an option to do their own choice of verification first. h> The idea here is similar to the web of trust in PGP/GNUPG. You do not h> know me, but you know someone that signed my PGP key stating I am who h> I say I am. However this arguement assumes that I have not met my brother or friend and do not have another method of validation such as voice p2p. Also another thought, I may want to exchange mails with someone I do not trust - however I'd prefer the option to reduce the chance of someone else listening in at least for most of the journey. 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> potentia
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
James Whitmoor wrote: (snip) I disagree, I control my local server and DNS, Redleg controls his local server and DNS. We could happily exchange messages in clear but for privacy would like the option to choose to validate each others certs by external methods. Yes, I know you control your DNS, and Redleg controls his/her. So... I leave your DNS (and Redleg's) alone, and go poison a DNS upstream. All I need is to have the remote user contact MY server first. Easy, unfortunately. And, what is worse, already done, many times over. End result: you will still believe you are all set & secure... Of course, this is still rather different from broadcasting -- I would be the only one able to follow your conversations. And, again of course, I might decide it's a good enough conversation to post out to the public. If you have external methods to guarantee the key, then you do not need rootless certificates. In fact (except if you are using self-signed certificates), you do not need TLS/SSL at all. (snip) For private use, personal private verification works fine. Browsers happily let you import a non-CA cert and allow a user an option to do their own choice of verification first. Yes... but you can set yours to at least warn you something (potentially) fishy is going on. Unfortunately, not many of the users do that. Also, I do not like the amount of root certificates given to us, by default, on Windows. But I certainly am *very* careful whenever I get to a site where I receive a certificate that does not match common name, or for which I have no root. However this arguement assumes that I have not met my brother or friend and do not have another method of validation such as voice p2p. Also another thought, I may want to exchange mails with someone I do not trust - however I'd prefer the option to reduce the chance of someone else listening in at least for most of the journey. This is valid only when all parties involved do have other means of certifying each other (like, as you point out, private comm, in loco meetings, etc). This does not apply to open-ended systems, like a HTTP server. And, if you want to exchange secure e-mail with somebody else, all you both need is to generate & exchange self-signed public certificates, and make sure both sides encrypt (or, of course, use PGP/GNUPG). An added bonus is signature and non-repudiation. But... you do not need, anymore, channel encryption. It can still be used, but you are not relying on it as the *sole* privacy measure. Please remember that most people (and web sites) use server-only authentication -- you rely on the server for all encryption, authentication, validation, and certification. This is a major part in my worries. If I have to rely on a third party (which I do not personally know), then I want a bit more of safety. Accepting a rootless certificate voids all inherent safety. Also, there are other means of securing a channel on a closed loop (i.e., where the parties know each other). You can use self-signed certificates here without any problems; you can use STS (Station-To-Station) encryption, which is pretty much like TLS/SSL, but without identification information; you can use PGP/GNUPG; etc, etc. TLS/SSL is built to allow you to secure a channel when the parties have *NOT* met, or do not physically know each other. It takes care of the key distribution problem for you. (snip) Cheers, ..hggdh.. 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello hggdh, Thank you for your detailed reply and pointers, looks like I have a bit more reading to do! -- Best regards, James 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello Allie, Sunday, October 24, 2004, 5:04:38 PM, you wrote: > On Sunday, October 24, 2004 at 2:09:21 PM [GMT -0500], Army Redleg > wrote: >> Understood, *if* these servers are indeed in violation of the >> "Standard"... > Yes. This is the question for which I don't have an answer. Unless we > know the answer, we cannot really make a strong claim either way. >> Which now begs the question, after searching through various FAQs, >> standards and proposals (IETF, ANS.1, ISO, etc)- I simply ended up with >> a headache- swimming eyes and reeling mind... > I know how you feel. I've tried looking up technical information like > that and rarely come up feeling enlightened. I usually feel exhausted > and frustrated. >> If you know where I can find this standard (will/must versus >> may/should), please point me in the general direction. > I can't. :) This is why I didn't want to put a foot in too deep. I have found a few things that are of interest- will be posting them in reply to hggdh. Worst thing is I cannot find a "Standard" so between the user, the server and the software developer there has to be some agreements and as you say the spirit or intent should be honored. funny thing is, my request does honor that :) more in a second or two. -- 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" 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
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. 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 quer
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello Mark! On Tuesday, October 26, 2004, 9:58 PM, you wrote: AR>>> Thanks for the feedback, looking forward to more- and hopefully AR>>> (eventually) even get entertained by the development powers that AR>>> be. Well, I do hope so, too, for the sake of your having your needs in your use of The Bat! met. 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). I have found it fun to be learning about these things by reading this thread, also. I do know how to open a formal wish, and have been putting notes to other people's formal wishes on Bug Tracker. AR> actually I thought my first post on the matter was the formal AR> wish...? Are you being ironic here, Mark? So hard for me to tell, lately, when simple irony is being employed. I think that hggdh means posting it on the Bug Tracker, Issues, Wish (Feature Request) section. Do you have an account at Bug Tracker? It's easy to get one. Just go here and sign up: https://www.ritlabs.com/bt/main_page.php The page's title is: RITLabs Issues and Bugs Tracking System. Feature requests can be made on an available form there, also. Stefan recently said that the programming team would like to have our reports of bugs and our feature requests placed there, for easier attention from them. In mid:[EMAIL PROTECTED] Stefan>>> To vote for your favourite pet peeves, just add a Stefan>>> shortcomment to reports on the Bugtraq - that would move the Stefan>>> report upthe list and we'll see what we can do with it. Of course, that was in relation to v. 3.01/RC1, but I think the principle no doubt still stands. AR> I will call it a "Feature Request" tomorrow then Put it at "RITLabs Issues and Bugs Tracking System" at the URL given above. :) h>> I will sign down on it (given that a stern warning is issued prior h>> to acceptance of the rootless public certificate). Mark, I think that he means he will put a note in the field supplied at RITLabs Issues and Bugs Tracking System. AR> Thank you, I will draft something up less whingy and more formal AR> looking before leaving for the weekend. Hopefully the subject will AR> receive comment from the developers... eventually... I do indeed expect it to. I am very much a novice with PGP, but I do have occasion to use its encryption from time-to-time. -- Best regards, Mary The Bat 3.0.2.1 on Windows XP 5.1 2600 Service Pack 2 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/
Re: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello Army, Tuesday, October 26, 2004, 21:58:41, you wrote: AR> Hello hggdh, AR> Sunday, October 24, 2004, 5:46:31 PM, you wrote: (HUGE snip) I did not forget you... I just need time to read it all & answer ;-) -- ..hggdh.. Using The Bat! v3.0.1.33 and BayesIt! 0.7.3 on Windows 2000 5.0 Build 2195 Service Pack 4 pgpJjd8rxhMAz.pgp Description: PGP signature Current beta is 3.0.2.2 | '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/
Re[2]: Feature wish- allow user to permanently permit session with "incomplete" SSL/TLS server certs
Hello Allie, Saturday, October 23, 2004, 4:36:00 PM, you wrote: AM> Not to worry. You'll not be admonished for bringing this up more than AM> once. this is good :) AM> However, the technically oriented members here tend to be sensitive AM> about TB! being accused of buggy behaviour when it simply fails to AM> cater to non-standard behaviour by servers. Understood, *if* these servers are indeed in violation of the "Standard"... Which now begs the question, after searching through various FAQs, standards and proposals (IETF, ANS.1, ISO, etc)- I simply ended up with a headache- swimming eyes and reeling mind... If you know where I can find this standard (will/must versus may/should), please point me in the general direction. AM> It doesn't really have to do this. It's the server admins who really AM> aught to get their act together. However, I'm pragmatic on issues as AM> these and understand that in the end, it's the users comfort and not AM> standards conformation battles that do matter at the very end. I do AM> realize that conformation to standards and user comfort do go hand AM> in hand, so the clients and servers really aught to remain AM> compliant. Although I feel TB! is the best client on the planet- and certainly the most flexible and powerful in configuration, I fail to see why it refuses to allow the user to make the choice in this circumstance. *If* these servers are in direct violation of published standards then I will humbly agree with everything folks say about killing my 'feature wish' and start begging the US Army/military and Cotse to get their act together and get in compliance with a referenced published standards and requirements... (but I will always hold out on TB! giving the User the power of choice in any email matter;) perhaps I just want TB! to sell me the gun and ammo- allow me to pull the trigger when I want to. AM> Providing workarounds is a really sensitive issue. Though it makes the AM> user less frustrated in the end, one wonders what it will do to those AM> who keep breaching the agreed on standards and getting away with it. AM> They'll breach it again, and again, and again. Should this be allowed AM> for security standards, especially when the breach is clearly not in the AM> spirit of good security? I would probably not bother this good group again if I could start arguing with those server admins on how they are breaching standards. But would argue your point here where you say it is not in the 'spirit of good security'. Spirit, perhaps the intent of the law- vice the letter of the law, is what my feature wish really is (if indeed these servers are in direct violation of the standard). If the standard says may or should- well then there is no real violation rather only a hardline approach to strict protocols that TB! refuses to permit any deviation from. If the standard does say will or must, then it is back to simply a feature wish by a lazy user who desires security and privacy afforded by this protocol with servers he/she trusts to transport his/her mail to and from the server. >> Discussion- >> Whenever the POP/IMAP/SMTP server fails to provide the root/CA >> certificate or full chain with the server certificate TB! pops up an >> "Unknown CA certificate" warning. AM> Shouldn't it? Yes it should. However, I would further desire TB! allowing the user to hash/fingerprint the accepted cert for more than one session, if the user so desires, and not have to manually OK this action each time. >> In this warning dialog box is a few buttons with "OK" and "CANCEL" >> always selectable, giving temporary/session permission, but "View >> Certificate" and "Add to Trusted" are not selectable unless the server >> provides a full certificate chain. AM> Well, the certificate cannot be viewed without all the information. How AM> can it be trusted without the full cert chain? So these are greyed out. Not true. A certificate should always be viewable how else can I even begin to know what TB! is warning me about in the first place? I cannot verify anything- simply know that TB! doesn't like something- not sure what it is, but that I should trust TB! on making the choice for me and allow me to initiate a single connection- again with encryption established with an unverifiable certificate. Does that really make any sense at all? TB! allows me to start a SSL or TLS session with an unverified certificate? >> Not being able to view and or add to trusted forces the user to >> manually OK the session each and every time a connection is made to >> these servers. On accounts where this is true and automatic checking >> for new mail is set this dialog box can be hidden behind other windows >> and even hang the client and/or system if not answered in a timely >> fashion. AM> So you're wishing for a trust anyway button? :) YES!! well, sorta- hitting OK is the "trust anyway" button. Allowing me to import what I want to import to my trusted certs is the "Trust Anyway"
