STARTTLS를 사용하는 http(80)의 TLS/SSL

STARTTLS를 사용하는 http(80)의 TLS/SSL

TLS/SSL이 HTTP를 통해 사용되지 않는 이유를 조사 중입니다. SMTP, POP3, FTP 등과 같은 다른 프로토콜을 SSL 포트(SMTP)에서 사용할 수 있습니다.에스, POP3에스, FTP에스) 첫 번째 방법이고, 두 번째 방법은 확장자(SMTP 예) 이메일 프로토콜에 두 번째 방법(STARTTLS)을 사용하는 널리 사용되는 방법이 있는데, http가 STARTTLS를 사용하지 않는 이유는 무엇입니까? 나는 찾았다HTTP/1.1 내의 RFC TLS, 하지만 요즘에는 사용하지 않습니다(또는 아직 본 적이 없을 수도 있습니다)

답변1

목적 중 하나는업그레이드 메커니즘~에RFC 2817제공은 다음과 같았습니다가상 호스팅2000년의 상황과 마찬가지로 TLS를 사용한 HTTP 메커니즘은 다음과 같습니다.

업그레이드 메커니즘은 "가상 호스팅" 문제도 해결합니다. 단일 호스트에 여러 IP 주소를 할당하는 대신 HTTP/1.1 서버는 Host: 헤더를 사용하여 의도한 웹 서비스를 명확하게 합니다. HTTP/1.1 사용이 더욱 보편화됨에 따라 더 많은 ISP가 이름 기반 가상 호스팅을 제공하여 IP 주소 공간 고갈을 지연시키고 있습니다.

그만큼서버 이름 표시(SNI;RFC 3546, 3.1)는 2003년에 이 문제에 대한 더 나은 솔루션(아직도 사용 중)을 제공했기 때문에 더 이상 이 문제가 필요하지 않았습니다. 헤더 Upgrade는 여전히 살아있지만 HTTP/1.1에서 HTTP/2.0으로 전환하는 등 다양한 목적으로 사용됩니다(RFC 7230, 6.7).

HTTP 프로토콜에는 헤더 Location(RFC 7231, 7.1.2)를 관련 응답 코드와 함께 사용하면 를 사용하는 프로토콜과 달리 클라이언트를 다른 체계, 호스트 및 포트로 쉽게 리디렉션할 수 있습니다 STARTTLS.

또한 사용하는 것은 STARTTLS좋지도 바람직하지도 않으며 더 많은 프로토콜에서 채택해야 하는 것도 아닙니다. 사실은,RFC 8314이제 이메일 제출 및 액세스를 위한 일반 텍스트 프로토콜을 더 이상 사용하지 않으므로 MTA-MTA SMTP를 STARTTLS사용해야 하는 유일한 이메일 프로토콜로 남겨둡니다. 에서섹션 3:

– – 이 메커니즘이 배포되었지만 별도의 포트에서 연결 시작 시 TLS가 즉시 협상되는 대체 메커니즘(이 문서에서는 "암시적 TLS"라고 함)이 더 성공적으로 배포되었습니다. TLS의 보다 광범위한 사용을 장려하고 TLS 사용 방법에 대한 일관성을 높이기 위해 이제 이 사양에서는 POP, IMAP, SMTP 제출 및 MUA와 MSP 간에 사용되는 기타 모든 프로토콜에 암시적 TLS를 사용할 것을 권장합니다.

답변2

한 가지 이유는 추가 왕복(요청 + 응답)이 필요하기 때문에 추가 STARTTLS가 더 많은 오버헤드를 추가하기 때문일 수 있습니다. 연결 시작부터 응답까지의 시간은 HTTP에서 상당히 중요하며, 이 시간을 줄이기 위해 더 짧은 TLS 핸드셰이크나 QUIC와 같은 다른 프로토콜과 같이 많은 최적화가 수행되었습니다. STARTTLS와 같은 것을 추가하면 시간이 늘어나므로 좋은 생각이 아닙니다.

관련 정보