[FIG(quote)[ [FIGCAPTION[ [1] [CITE@en[RFC 7457 - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)]] ([TIME[2015-02-24 18:52:35 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [2] [[IETF]] は [[RFC 2817]] で本方式を [CODE(HTTP)@en[[[Upgrade:]] [[TLS]]]] という形で [[HTTP]] に持ち込むことを企てましたが、支持されませんでした。 [3] [[IETF]] は[[ポート番号]]の枯渇を懸念して、 [[HTTP]] と [[HTTPS]] のように異なる[[ポート]]を使う方法よりも [[STARTTLS]] のような[[命令]]を[[アプリケーション層プロトコル]]に含める方式が望ましいとしているようです。 ;; [[TLS]] も参照。 [4] [[STARTTLS]] 方式は転送路とアプリケーションを分離する階層化された設計を否定する、 [[layering violation]] のようにも思えます。 アプリケーションプロトコル内部で平文モードから [[TLS]] モードや [[TLS]] モードから平文モードへの切り替えを実装しなければならないため、 [[セキュリティー]]上の問題をプロトコルや実装に生じさせてしまう例が実際にあったと [[RFC 7472]] は述べています。そうでなくても、広義の[[ソケット層]]の [[TLS]] と[[アプリケーション層]]で比較的綺麗にモジュール化できたはずのアプリケーション層プロトコルの実装が [[STARTTLS]] 方式では複雑になってしまいます。 [FIG(quote)[ [FIGCAPTION[ [5] [CITE@en[RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]] ([TIME[2015-05-29 03:22:56 +09:00]] 版) ]FIGCAPTION] > 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. > ]FIG] [FIG(quote)[ [FIGCAPTION[ [6] [CITE@en[RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme]] ([TIME[2015-05-25 01:18:35 +09:00]] 版) ]FIGCAPTION] > 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!". ]FIG] [FIG(quote)[ [FIGCAPTION[ [7] [CITE@en[RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]] ([TIME[2015-05-29 03:22:56 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [8] [CITE@ja[認証メールを送るときには、587(starttls)じゃなくて、465(smtps)を使おう]], [TIME[2024-12-04T07:23:06.000Z]]