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 のような命令をアプリケーション層プロトコルに含める方式が望ましいとしているようです。
[4] STARTTLS 方式は転送路とアプリケーションを分離する階層化された設計を否定する、 layering violation のようにも思えます。 アプリケーションプロトコル内部で平文モードから TLS モードや TLS モードから平文モードへの切り替えを実装しなければならないため、 セキュリティー上の問題をプロトコルや実装に生じさせてしまう例が実際にあったと RFC 7472 は述べています。そうでなくても、広義のソケット層の TLS とアプリケーション層で比較的綺麗にモジュール化できたはずのアプリケーション層プロトコルの実装が STARTTLS 方式では複雑になってしまいます。
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.
[8] 認証メールを送るときには、587(starttls)じゃなくて、465(smtps)を使おう, https://zenn.dev/bitcat/articles/4f2c7d717b3053