[1] RFC 7457 - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) ( 版) https://tools.ietf.org/html/rfc7457#section-2.2

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.

[2] IETF は RFC 2817 で本方式を Upgrade: TLS という形で HTTP に持ち込むことを企てましたが、支持されませんでした。

[3] IETF はポート番号の枯渇を懸念して、 HTTP と HTTPS のように異なるポートを使う方法よりも STARTTLS のような命令をアプリケーション層プロトコルに含める方式が望ましいとしているようです。

TLS も参照。

[4] STARTTLS 方式は転送路とアプリケーションを分離する階層化された設計を否定する、 layering violation のようにも思えます。 アプリケーションプロトコル内部で平文モードから TLS モードや TLS モードから平文モードへの切り替えを実装しなければならないため、 セキュリティー上の問題をプロトコルや実装に生じさせてしまう例が実際にあったと RFC 7472 は述べています。そうでなくても、広義のソケット層の TLS とアプリケーション層で比較的綺麗にモジュール化できたはずのアプリケーション層プロトコルの実装が STARTTLS 方式では複雑になってしまいます。

[5] RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) ( 版) https://tools.ietf.org/html/rfc7525#section-3.2

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.

[6] RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme ( 版) https://tools.ietf.org/html/rfc7472

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!".

[7] RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) ( 版) https://tools.ietf.org/html/rfc7525#section-3.2

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.

[8] 認証メールを送るときには、587(starttls)じゃなくて、465(smtps)を使おう, https://zenn.dev/bitcat/articles/4f2c7d717b3053