Closed Bug 1119330 Opened 8 years ago Closed 8 years ago

Allow SSLv3 for STARTTLS

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: emk, Unassigned)

References

Details

Attachments

(1 file)

- Mail servers/clients tend to be slower to update than HTTP servers/user-agents.
- The POODLE attack is not applicable to SMTP servers as of now.
- STARTTLS is already vulnerable to active MiTM attacks anyway.
Attachment #8546008 - Flags: review?(dkeeler)
Wouldn't a separate pref be better for this? (default to true in release, if actually needed) If people do want to disable SSL3 here, they won't be able to unless they also disable TLS 1.0, which is not intuitive or necessarily desired.
Comment on attachment 8546008 [details] [diff] [review]
allow_sslv3_for_starttls

Review of attachment 8546008 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, unfortunately I only see this working as a separate pref. The main problem I see is we can't differentiate between a user who wants the defaults (i.e. to use SSL 3.0 only with STARTTLS) and a user who wants only TLS 1.0-1.2 enabled (i.e. to not use SSL 3.0 with STARTTLS).
Attachment #8546008 - Flags: review?(dkeeler) → review-
I would tread really carefully here - and I'm commenting without doing all my due dilligence code reading, so perhaps I'm wrong.

I don't think psm's starttls usage is limited only to smtp usage - in particular I think that code path is also used by the HTTP CONNECT method to establish a TLS tunnel inside an existing HTTP connection to a proxy.
I don't know if it matters (reading the patch it appears not), but STARTTLS is also configurable and used for the IMAP and POP mail protocols (I don't know about LDAP).

As for establishing an encrypted tunnel over HTTP in this way (comment #3), wouldn't this be subject to the same active MiTM attacks as mail protocols anyway (comment #0, point #3), given that STARTTLS would be the same mechanism in all cases regardless of the target protocol?
(In reply to rsx11m from comment #4)

> As for establishing an encrypted tunnel over HTTP in this way (comment #3),
> wouldn't this be subject to the same active MiTM attacks as mail protocols
> anyway (comment #0, point #3), given that STARTTLS would be the same
> mechanism in all cases regardless of the target protocol?

no because http connect would fail hard in that scenario - contrasted with smtp where its opportunistic based on an advertisement.
I'd like to challenge the assertion that poodle doesn't apply. I know that Kenny Patterson was looking at mounting attacks on smtp that relied on repeated plaintext early in the connection with his rc4 work. I think that in general, this is fine to split out, by pref as suggested. But I'm not sanguine about re-enabling ssl here.
Hm, probably we should not do this.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to Masatoshi Kimura [:emk] from comment #7)
> Hm, probably we should not do this.
> Resolution: --- → WONTFIX

+1

If a mail server is SSLv3 only, you may use no encryption anyway. Or you just flip the pref.
(In reply to Patrick McManus [:mcmanus] from comment #3)
> I would tread really carefully here - and I'm commenting without doing all
> my due dilligence code reading, so perhaps I'm wrong.
> 
> I don't think psm's starttls usage is limited only to smtp usage - in
> particular I think that code path is also used by the HTTP CONNECT method to
> establish a TLS tunnel inside an existing HTTP connection to a proxy.

For the record, forSTARTTLS will not be true for HTTP CONNECT. See bug 969479.
You need to log in before you can comment on or make changes to this bug.