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.

In cases where an application protocol allows implementations or

deployments a choice between strict TLS configuration and dynamic

upgrade from unencrypted to TLS-protected traffic (such as

STARTTLS), clients and servers SHOULD prefer strict TLS

configuration.

1) Some existing IPP Client and IPP Printer implementations of

"Upgrading to TLS Within HTTP/1.1" [RFC2817] are flawed and

unreliable, although this is not due to specification defects in

[RFC2817] itself.

2) Some existing IPP Client and IPP Printer implementations of HTTP

upgrade [RFC2817] do not perform an upgrade at the beginning of

every HTTP [RFC7230] connection; instead, they only shift to

secure IPP for selected IPP operations (inherently dangerous

behavior on the same underlying TCP [RFC793] connection).

3) IPP Printer server-mandated HTTP upgrade [RFC2817] can still lead

to exposure of IPP Client data if the Expect request header is not

used -- basically, the IPP Client can send its whole Print-Job

request before the IPP Printer has a chance to respond and say,

"Wait! You need to encrypt first!".

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.