Re: [Imap-protocol] STARTTLS after PREAUTH
Dave Cridland <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <CAKHUCzzu3atA=3gyVBJhNEKNy-hRM2+d0HmptkfbiKM1DQw4Hg@mail.gmail.com> |
On 19 March 2014 02:23, Bron Gondwana <[email protected]> wrote: > I'd be interested in seeing the actual stats for which clients can be > convinced by a MITM to give up their credentials in plaintext in their > default configuration. Don't give me a checkbox which requires the user to > actively increase the security level, because that won't work. In fact, > don't even give the user a dialog which allows them to send the password > insecurely, because they will. > Inky does a single leap-of-faith to handle unverified certificates during its account setup phase, and won't (ever) send passwords insecurely. This limits providers alarmingly; many "free with your internet" providers still seem to insist on cleartext passwords and no TLS. The leap-of-faith is needed because it performs RFC 6186 lookups, as well as heuristic discovery, and providers do not supply verifiable SANs in this case - that is, Inky's only reference identifiers [RFC 6125] are typically domains like "fastmail.fm" or "gmail.com" rather than hostnames supplied directly by the user. In these example cases, the provider supplies RFC 6186 records authoritatively: ;; ANSWER SECTION: _imaps._tcp.gmail.com. 86400 IN SRV 5 0 993 imap.gmail.com. ;; ANSWER SECTION: _imaps._tcp.fastmail.fm. 600 IN SRV 0 1 993 mail.messagingengine.com. However trusting these requires either DNSSEC (which I'm not sure either domain supports; Inky certainly doesn't) or for the certificates to include an identifier for either the domain (which I don't think they do) or the service+domain restricted identifier (via sRVNames for example). I think a good first step to helping MUA developers rely on a valid trust path would be to ensure that a valid trust path actually exists (whether that's via DNSSEC or sRVName SANs). Then you're in a much better position to denounce the client developers for how awful and slack they are. :-) Dave. _______________________________________________ Imap-protocol mailing list [email protected] http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol