Hi Yaron,
Actually I think the paragraph reads better in Sec. 2.2 because Sec. 2.1
is all about HTTP, but we should have picked a more inclusive heading
for 2.2, maybe "STARTTLS and the STARTTLS Command Injection Attack
(CVE-2011-0411)".
In that case, there would be a reference problem with RFC 7525 because
Section 3.2 of RFC 7525 mentions Section 2.1 for lack of STARTTLS (and
not 2.2):
The following recommendations are provided to help prevent SSL
Stripping (an attack that is summarized in Section 2.1 of [RFC7457]):
o Application protocols typically provide a way for the server to
offer TLS during an initial protocol exchange, and sometimes also
provide a way for the server to advertise support for TLS (e.g.,
through a flag indicating that TLS is required); unfortunately,
these indications are sent before the communication channel is
encrypted. A client SHOULD attempt to negotiate TLS even if these
indications are not communicated by the server.
--
Julien
On 19/12/16 23:42, Julien ÉLIE wrote:
Hi all,
In RFC 7457 "Summarizing Known Attacks on Transport Layer Security (TLS)
and Datagram TLS (DTLS)", shouldn't the second paragraph of Section 2.2
have been placed in Section 2.1 instead?
I believe it is linked to SSL stripping, and not an injection attack.
I can open an erratum if you confirm that.
RFC 7457 currently reads:
2.1. SSL Stripping
Various attacks attempt to remove the use of Secure Socket Layer /
Transport Layer Security (SSL/TLS) altogether by modifying
unencrypted protocols that request the use of TLS, specifically
modifying HTTP traffic and HTML pages as they pass on the wire.
These attacks are known collectively as "SSL Stripping" (a form of
the more generic "downgrade attack") and were first introduced by
Moxie Marlinspike [SSL-Stripping]. In the context of Web traffic,
these attacks are only effective if the client initially accesses a
Web server using HTTP. A commonly used mitigation is HTTP Strict
Transport Security (HSTS) [RFC6797].
2.2. STARTTLS Command Injection Attack (CVE-2011-0411)
Similarly, there are attacks on the transition between unprotected
and TLS-protected traffic. A number of IETF application protocols
have used an application-level command, usually STARTTLS, to upgrade
a cleartext connection to use TLS. Multiple implementations of
STARTTLS had a flaw where an application-layer input buffer retained
commands that were pipelined with the STARTTLS command, such that
commands received prior to TLS negotiation are executed after TLS
negotiation. This problem is resolved by requiring the application-
level command input buffer to be empty before negotiating TLS. Note
that this flaw lives in the application layer code and does not
impact the TLS protocol directly.
STARTTLS and similar mechanisms are vulnerable to downgrade attacks,
whereby the attacker simply removes the STARTTLS indication from the
(unprotected) request. This cannot be mitigated unless HSTS-like
solutions are added.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
