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... <g> > 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" > button I seek! >>> 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). >>> ==== 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? > oh boy... <g> > I do hope it truly seems reasonable. I am very security and privacy > oriented and desire to be permitted to make my own decisions on the > matter regards how important I feel whether a complete certificate chain > is presented or not when I wish to establish an encrypted transport for > safe email exchange with servers I determine to be trusted. > 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. > Thanks for the feedback Allie, look forward to yours and others response > regarding this subject. -- -= 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/
