제 7장 웹을 안전하게 지켜주는 HTTPS

HTTP의 약점

• 평문(암호화하지 않은) 통신이기 때문에 도청 가능
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없기 때문에 변조 가능

 

평문이기 때문에 도청 가능

• TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있다.
• 암호화된 통신도, 암호화되지 않은 통신도 모두 엿볼 수 있다.
  암호화된 통신은 메세지 속의 의미는 간파할 수 없어도 암호화된 메세지 자체는 엿볼 수 있다.
• 도청으로부터 정보를 지키기 위한 방법 중 가장 보급되어 있는 기술은 암호화이다.
  
  1. 통신 암호화
  - SSL, TLS라는 다른 프로토콜을 조합해서 HTTP의 통신 내용을 암호화 할 수 있다.
  - SSL 등을 통해 안전한 통신로를 확립하고 나서 그 통신로를 사용해 HTTP 통신을 한다.
  - SSL을 조합한 HTTP를 HTTPS나 HTTP over SSL이라 불리고 있다.
  
  2. 콘텐츠 암호화
  - 통신하고 있는 콘텐츠의 내용 자체를 암호화하는 방법이다.
  - 이 경우 클라이언트에서 HTTP 메세지를 암호화해서 출력하는 처리가 필요하다.
  - 콘텐츠의 암호화를 유효하게 하기 위해서는 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 것이 전제가 된다.
     평상시에 유저가 사용하는 브라우저와 웹 서버에서 이용하는 것은 어려워서 주로 웹 서비스 등에서 이용되는 방법이다.

 

통신 상대를 확인하지 않기 때문에 위장 가능

• HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있다.
• 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다.
• 그에 따른 약점
  - 리퀘스트를 보낸 곳, 리스폰스를 반환 곳이 의도한 곳인지 아닌지를 확인 할 수 없다.
  - 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다.
  - 어디의 누가 리퀘스트를 했는지 확인할 수 없다.
  - 의미없는 리퀘스트라도 수신하게 된다. 대량의 리퀘스트에 의한 DoS 공격을 방지할 수가 없다.
• SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공한다.
  증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되어 서버나 클라이언트가 실재하는 사실을 증명한다.

 

완전성을 증명할 수 없기 때문에 변조 가능

• 리퀘스트나 리스폰스가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었다고 하더라도 이 사실을 알 수 없다.
• 변조를 방지하려면?
  - 현재는 MD5나 SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 자주 쓰인다.
  - 그러나 이 방법으로 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용할 필요가 있다.

 

---

 

HTTPS

(HTTP+인증+암호화+완전성 보호)
HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS(HTTP Secure)라고 부른다.

HTTP는 SSL의 껍질을 덮어쓴 HTTP

HTTP 통신을 하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체하고 있는 것을 HTTPS라고 한다.
HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.

 

상호간에 키를 교환하는 공개키 암호화 방식

SSL에서는 공개키 암호화 방식을 채용하고 있다.

• 공통키 암호
  - 암호화와 복호화에 하나에 키를 사용하는 방식
  - 네크워크를 사용해서 키를 넘겨줄 때 통신이 도청되어 키를 빼앗기면 암호와의 의미가 없어진다.
  
  
• 공개키 암호
  - 비밀키(private key)와 공개키(public key)를 사용하는 방식
  - 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 하고, 상대는 자신의 비밀키를 사용해 복호화한다.
  
  
• HTTPS는 하이브리드 암호 시스템
  - 공개키 암호는 공통키 암호에 비해서 처리 속도가 느리다.
  - 두 가지 장점을 살릴 수 있도록 각각의 방식을 조합해 통신한다.
  - 키를 교환하는 곳에서는 공개키 암호를, 메세지를 교환하는 곳에서는 공통키 암호를 사용한다.

 

공개키가 정확한지 아닌지를 증명하는 증명서

공개키 암호화 방식은 공개키가 진짜인지 아닌지를 증명할 수 없다는 문제점이 있다.
이 문제를 해결하기 위해 인증기관(CA : Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용된다.

<인증 과정>

1. 서버는 서버의 공개키를 인증기관에 등록한다.
2. 인증기관은 인증기관의 비밀키로 서버의 공개키에 디지털 서명을 하고 공개키 증명서를 작성하고 등록한다.
3. 클라이언트는 서버의 공개키 증명서를 입수하고, 인증기관의 공개키로 디지털 서명을 검증하고 진짜인지 확인한다.
4. 클라이언트는 서버의 공개키로 암호화해서 메세지를 송신 기관에 등록한다.
5. 서버는 서버의 비밀키로 메세지를 복호화한다.

주요 인증기관의 공개키는 대체로 웹 브라우저에서 사전에 내장한 상태이다.

 

• 조직의 실제성을 증명하는 EV SSL 증명서
  - 상대방이 실제로 있는 기업인지 확인하는 증명서
  - 세계 표준의 인정 가이드라인에 의해서 발행되는 증명서로, 조직의 실재성을 확인하는 방법을 엄격히 규정하고 있기 때문에 웹 사이트의 신뢰성을 높인다.
  
  
• 클라이언트를 확인하는 클라이언트 증명서
  - 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증
  - 문제점
    1. 유저가 클라이언트 증명서를 인스톨 해야하는데,
        클라이언트 증명서는 유로로 구입할 필요가 있기 때문에 유저 수 만큼 비용이 든다.
    2. 클라이언트의 실재를 증명할 뿐, 사용자의 존재 유무를 증명하는 증명서는 아니다. 
  
  
• 인증 기관은 신용이 제일
  - SSL은 인증 기관을 신용할 수 있다는 전제로 이루어져 있다.
  - 잘못 발행된 증명서라고 해도 믿을 수 있는 인증 기관의 서명이 있으면 브라우저는 올바른 증명서로 인식한다.
  
  
• 자기 인증 기관 발행 증명서는 '나야 나' 증명서
  - OpenSSL 등의 소프트웨어를 사용하면 누구든지 인증기관을 구축할 수 있다.
    그러나 이 서버 증명서는 인터넷 상에서는 증명서로서 구실을 하지 못하며 쓸모가 없다.
    위장의 가능성을 불식할 수 없기 때문이다.

 

SSL은 느리다?

• HTTPS는 서버, 클라이언트 모두 암호화와 복호화 처리가 필요하기 때문에 CPU나 메모리 등의 하드웨어 리소스를 소비한다.
• HTTP 통신에 비해서 SSL통신만큼 네트워크 리소스를 더 소비한다.
  또한 SSL통신만큼 통신 처리에 시간이 걸린다.
• 느려지는 것은 근본적인 해결 방법은 없기 때문에 SSL 엑셀레이터라는 하드웨어를 사용해서 문제를 해결하기도 한다.
  SSL을 처리하기 위한 전용 하드웨어로 SSL을 소프트웨어로 처리할 때 보다 몇 배 빠른 계산을 할 수 있다.

 

왜 항상 보안에 유리한 HTTPS를 사용하지 않는가?

• 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하기 때문이다.
  그래서 주로 개인정보 등 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다.
• 증명서를 구입하는 비용이 들기 때문이다.
  HTTPS를 사용하기 위해서는 증명서가 필요하고, 증명서는 CA에서 구입해야 한다.

 

 

 

출처 : 그림으로 배우는 Http&Network Basic