시큐어 하이퍼텍스트 전송
Secure Hypertext Transfer Protocol| HTTP |
|---|
 |
| 요구 방식 |
| 헤더 필드 |
| 응답 상태 코드 |
| 보안 접근 제어 방법 |
| 보안 취약성 |
S-HTTP(Secure Hypertext Transfer Protocol)는 인터넷을 통해 전송되는 웹 통신을 암호화하기 위한 HTTPS 프로토콜의 오래된 대안입니다.그것은 에릭 레스콜라와 앨런 M에 의해 개발되었다.1994년[1] EIT의 Schiffman과 1999년 출판. RFC2660.
S-HTTP가 처음 시장에 [2]나왔지만 넷스케이프의 브라우저 시장 장악으로 HTTPS는 사실상 웹 통신 보안 수단이 됐다.
HTTP over TLS와의 비교
S-HTTP는 POST 필드와 같이 제공된 페이지 데이터 및 제출된 데이터만 암호화하고 프로토콜의 시작은 변경되지 않습니다.이것에 의해, S-HTTP 는 같은 포토상에서 HTTP(시큐어 없음)와 동시에 사용할 수 있습니다.이는 암호화되지 않은 헤더가 나머지 전송의 암호화 여부를 판단하기 때문입니다.
반면 HTTP over TLS는 Transport Layer Security(TLS; 이전 SSL) 내에서 전체 통신을 래핑하므로 프로토콜 데이터가 전송되기 전에 암호화가 시작됩니다.이로 인해 어떤 DNS 이름을 요청에 사용할지 결정하는 이름 기반 가상 호스팅 "chicken and egg" 문제가 발생합니다.
즉, Server Name Indication(SNI; 서버 이름 표시)을 지원하지 않음HTTPS 실장에서는 DNS 이름별로 별도의 IP 주소가 필요하며, 모든 HTTPS 실장에서는 암호화(대부분의 브라우저에서는 별도의 URI 스킴으로 취급됨)를 명확하게 사용하기 위해 별도의 포트(통상은 443 대 HTTP 표준 80)[3]가 필요합니다.
RFC 2817에 기재되어 있듯이 HTTP/1.1 Upgrade 헤더를 구현하여 TLS로 업그레이드함으로써 HTTP를 보호할 수도 있습니다.이 방법으로 네고시에이트된HTTP over TLS 를 실행해도, 이름 베이스의 가상 호스팅에 관한 HTTPS 의 영향은 없습니다(추가 IP 주소, 포토, 또는 URI 스페이스는 없습니다).그러나 이 방법을 지원하는 구현은 거의 없습니다.
S-HTTP 에서는, 목적의 URL 는 클리어 텍스트헤더로 송신되지 않고, 공백인 채로 있습니다.암호화된 페이로드 내에 다른 헤더세트가 존재합니다.HTTP over TLS에서는 모든 헤더가 암호화된 페이로드 내에 있으며 서버 응용 프로그램은 일반적으로 TLS 치명적인 오류('클라이언트 증명서가 신뢰할 수 없음' 및 '클라이언트 증명서가 [citation needed]만료되었습니다' 등)로부터 정상적으로 복구할 수 없습니다.
레퍼런스
- ^ "The Secure HyperText Transfer Protocol". ietf.org. IETF. I-D draft-ietf-wts-shttp-01.txt. Retrieved 8 February 2022.
- ^ Lewis, Peter (12 August 1994). "Attention Shoppers: Internet Is Open". New York Times. Retrieved 8 February 2022.
- ^ Tom Sheldon (2001). "S-HTTP (Secure Hypertext Transfer Protocol)". Retrieved 2016-01-01.
