S-HTTP와 HTTPS: 메시지 단위 웹 보안의 역사와 의미
S-HTTP의 메시지 레벨 보안 방식, HTTPS와의 차이, 기술적 구성과 현대 웹 보안에 남긴 의미를 정리한다.
2026-08-14 · 최초 발행 2025-06-28
HTTP 메시지를 직접 보호하려 했던 S-HTTP
S-HTTP(Secure HTTP)는 1994년에 개발된 웹 보안 프로토콜이다. HTTP 위에 별도 보안 기능을 덧씌우는 것이 아니라, HTTP 메시지 자체에 암호화 기능을 추가하는 확장 방식이다.
이 방식은 웹 트랜잭션에 기밀성, 인증, 무결성, 부인방지 기능을 제공한다. 현재 웹에서는 HTTPS가 사실상 표준이지만, S-HTTP는 웹 통신 보안이 어떤 방향으로 발전할 수 있는지를 일찍 보여준 프로토콜이었다.
협상한 뒤 메시지 단위로 보안을 적용하는 방식
S-HTTP에서는 클라이언트와 서버가 협상을 통해 암호화 방식과 키 교환 방식을 결정한다. 이후 요청과 응답 각각에 보안 기능을 적용할 수 있다. 연결 전체가 아니라 개별 메시지가 보안 적용의 단위라는 점이 핵심이다.
HTTP 헤더에는 보안 처리를 위한 정보가 추가된다. Secure-HTTP-Version은 S-HTTP 버전을, Content-Privacy-Domain은 사용된 암호화 방식을 나타낸다. 암호화된 데이터 유형은 Content-Type으로 표현하며, Content-MAC과 Signature는 각각 메시지 인증 코드와 디지털 서명 정보를 담는다.
이 구조를 통해 다음 보안 서비스를 제공한다.
- 기밀성(Confidentiality): 데이터를 암호화해 제3자의 도청을 막는다.
- 인증(Authentication): 통신 상대방의 신원을 확인한다.
- 무결성(Integrity): 전송 과정에서 데이터가 바뀌었는지 확인한다.
- 부인방지(Non-repudiation): 발신자가 나중에 메시지 발신 사실을 부인하지 못하게 한다.
HTTPS와 갈린 보안 적용 범위
S-HTTP와 HTTPS는 모두 웹 통신을 보호하려는 목적을 갖지만, 보호 단위와 프로토콜 결합 방식이 다르다.
| 특성 | S-HTTP | HTTPS |
|---|---|---|
| 개발 시기 | 1994년 | 1994년(Netscape) |
| 보안 레벨 | 메시지 레벨 | 전송 레벨 |
| 프로토콜 스택 | HTTP 메시지 자체를 암호화 | HTTP를 SSL/TLS 위에서 실행 |
| 포트 | HTTP와 동일(80) | 443 |
| 유연성 | 각 메시지마다 다른 보안 옵션 적용 가능 | 연결 전체에 동일한 보안 적용 |
| 현재 사용도 | 거의 사용되지 않음 | 웹 표준으로 광범위하게 사용 |
S-HTTP는 메시지마다 다른 보안 옵션을 줄 수 있다는 유연성이 있었다. 반면 HTTPS는 통신 채널 전체를 암호화하는 통합된 모델을 제공했다. 웹 생태계에서는 후자의 단순한 적용 방식이 더 널리 받아들여졌다.
암호화와 인증을 묶는 구성
S-HTTP는 대칭키 암호화로 DES, RC2, IDEA 등을 지원했고, 공개키 암호화로 RSA를 지원했다. 키 교환에는 RSA와 Diffie-Hellman 알고리즘을 활용했다.
인증 체계로는 X.509 인증서와 PGP(Pretty Good Privacy) 인증 메커니즘을 지원했으며, 인증기관(CA) 기반 신뢰 모델도 활용했다. 메시지 무결성은 MAC(Message Authentication Code)으로 확인하고, MD5와 SHA-1 등의 해시 함수 및 디지털 서명을 통해 메시지 인증과 부인방지 기능을 제공했다.
웹 보안의 초기 표준으로 남은 배경
S-HTTP는 1994년 EIT(Enterprise Integration Technologies)에 의해 개발됐고, 웹 통신을 위한 초기 보안 프로토콜 가운데 하나로 IETF에서 RFC 2660으로 표준화됐다. 같은 시기 Netscape의 SSL이 등장했고, SSL은 이후 TLS로 발전했다.
시장에서는 SSL/TLS 기반 HTTPS가 더 널리 채택됐다. S-HTTP가 밀려난 배경에는 다양한 보안 옵션과 협상 과정에서 생기는 구현 복잡성, 주요 브라우저의 SSL/TLS 기반 HTTPS 채택, 메시지별 보안 옵션 관리의 확장성 문제가 있었다. HTTPS는 전체 통신 채널을 암호화하는 접근을 제공했고, Netscape의 SSL은 더 강한 상업적 지원을 받았다.
메시지 레벨 보안이 남긴 활용 관점
S-HTTP의 메시지 단위 보호 개념은 이후 XML 암호화와 JSON 웹 암호화(JWE)에 영향을 남겼다. RESTful API 보안, JSON 웹 토큰(JWT), XML 보안에서도 메시지 수준의 보호라는 관점을 찾을 수 있다. OAuth 2.0, JWE(JSON Web Encryption), WS-Security 역시 이런 흐름과 연결해 볼 수 있다.
금융 시스템처럼 트랜잭션별로 다른 보안 수준이 필요한 환경에서는 이 개념이 특히 유용하다. 일반 계좌 조회와 자금 이체 트랜잭션에 서로 다른 보안 수준을 적용하는 경우가 이에 해당한다.
의료 정보 시스템에서도 환자 정보의 민감도에 따라 다른 보안 레벨을 적용할 수 있다. 일반 진료 기록과 정신과 진료 기록에 다른 암호화 강도를 적용하는 방식이다.
현재 기준에서 남는 운영상의 경계
초기 S-HTTP가 지원하던 DES와 MD5 등은 현재 보안 취약점이 존재한다. 메시지별로 다른 키를 사용하면 키 관리가 복잡해질 수 있으며, 다양한 인증 메커니즘을 지원하는 구조는 인증서 관리 문제로도 이어질 수 있다.
S-HTTP 자체는 HTTPS에 자리를 내줬지만, 전송 레벨 보안과 메시지 레벨 보안을 함께 고려해야 하는 특수한 상황에서는 두 접근을 결합하는 하이브리드 방식이 의미를 가질 수 있다.