[Network] HTTPS 구조

HTTP 약점

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

 

1. 평문이기 때문에 도청 가능

• TCP/IP는 도청 가능한 네트워크
• 암호화로 도청 피할 수 있다
  • 통신을 암호화 : HTTP + SSL/TLS 조합
    • SSL(Secure Socket Layer)
    • TLS(Transport Layer Security)
    • SSL 등을 이용해 안전한 통신로를 확립 후, 그 통신로를 사용해 HTTP 통신
    • SSL을 조합한 HTTP => HTTPS(HTTP Secure) / HTTP over SSL
  • 콘텐츠 암호화: 콘텐츠 내용 자체를 암호화(HTTP메시지에 포함되는 콘텐츠만 암호화)
    • 메시지 헤더는 암호화되어 있지 않음
    • 메시지 바디에 들어가는 콘텐츠를 암호화(통신자체는 암호화되어 있지 않음)
    • 주로 웹 서비스에서 이용되는 방법

 

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

HTTP를 사용한 리퀘스트나 리스폰스 에서는 통신 상대를 확인하지 않음

• 누구나 리퀘스트 할 수 있음
  • 위장한 웹 서버일 우려
  • 위장한 클라이언트일 우려
  • 통신하고 있는 상대가 접근 허가된 상대인지 아닌지 확인할 수 없음
  • 어디의 누가 리퀘스트 했는지 확인할 수 없음
  • 의미없는 리퀘스트라도 수신하게 됨(DoS 공격 방지 불가능)
• 상대를 확인하는 증명서
  • SSL로 상대 확인 가능
  • SSL은 암호화 뿐 아니라, 상대를 확인하는 수단으로 증명서를 제공함
  • 클라이언트는 통신을 개시할 때 서버의 증명서를 확인함
  • 증명서를 가짐으로써 본인 확인 및 웹 사이트 인증에 이용 가능

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

완전성: 정보의 정확성

완전성을 증명할 수 없다: 정보가 정확한 지 아닌지 확인할 수 없다

• 수신한 내용이 다를지도 모른다
  • 리퀘스트/리스폰스가 발신된 후 상대가 수신할 때까지의 사이에, 변조되었다 하더라도 이 사실을 알 수 없음
  • 중간자 공격(Man-in-the-Middle 공격): 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격
• 변조를 방지하려면?
  • MD5/SHA-1 등 해시값 확인
  • 파일의 디지털 서명을 확인

 

HTTP+암호화+인증+완전성 보호 = HTTPS

1. HTTPS(HTTP Secure): HTTP에 암호화나 인증 등의 구조를 더한 것

• 증명서는 서버 혹은 클라이언트의 신원을 증명
• https://

 

2. HTTPS는 SSL의 껍질을 덮어쓴 HTTP

• HTTP 통신을 하는 소켓부분을 SSL이나 TLS라고 하는 프로토콜로 대체할 뿐, HTTPS는 새로운 프로토콜이 아니다

 

애플리케이션(HTTP)

TCP

IP

HTTP

애플리케이션(HTTP)

SSL

TCP

IP

HTTPS

HTTP는, 직접 TCP와 통신
HTTPS는, SSL을 사용한 경우, HTTP와 SSL이 통신하고, SSL이 TCP와 통신

 

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

SSL은 실제 데이터를 암호화 할 때 대칭키 암호화를 사용(암호화 알고리즘 공개하고, 키를 비밀에 부침)

• 대칭키(공통키) 암호의 딜레마: 키 배송 문제
  • 암호화할때도 복호화할 때도 같은 키를 사용
  • 키를 손에 넣으면 누구라도 암호를 해독할 수 있음
  • 키를 보내면 도청 될 가능성이 있고, 키를 보내지 않으면 복호화 할 수 없음
  • 애초에 키를 안전하게 보낼 수 있다면, 틀림없이 데이터도 안전하게 보낼 수 있음
  • 어떻게 하면 안전하게 키를 보낼 수 있을까?

4.  두개의 키를 사용하는 공개키(비대칭키) 암호

• 서로 다른 두 개의 키 쌍을 사용(비밀키-공개키)
• 암호를 보내는 쪽이 상대의 공개키를 사용해서 암호화 함
• 암호화된 정보를 받은 상대는 자신의 비밀키를 사용해 복호화 함
• 공개키는 누구에게나 넘겨줘도 괜찮음
• 대칭키 암호의 딜레마였던 키 배송 문제 해결

HTTPS는 하이브라드 암호시스템

• 키를 교환하는 곳에서는 공개키 암호 사용
• 그 후, 통신에서 메시지를 교환하는 곳에서는 대칭키(공통키)암호 사용

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

인증기관(CA: Certificate Authority)

1. 서버의 운영자가 인증기관에 공개키 제출
2. 인증기관은 제출된 공개키에 디지털 서명을 하고, 서명이 끝난 공개키를 생성 후 공개키 인증서에 서명이 끝난 공개키를 담는다
3. 서버는 이 인증기관에 의해 작성된 공개키 인증서를 클라이언트에 전송하고, 공개키 암호로 통신
4. 증명서를 받은 클라이언트는 증명기관의 공개키를 사용해서 서브의 공개키를 인증한 것이 진짜 인지, 서버의 공개키를 신뢰할 수 있는지 알수 있음

 

• 조직의 실제성을 증명하는 EV SSL 증명서
• 증명서 역할: 서버가 올바른 통신 상대임을 증명하는 것.
• EV SSL 증명서: 상대방이 실제 있는 기업인지 확인하는 역할을 가진 증명서. 운영하는 조직의 실재성 확인
• 클라이언트 증명서

 

HTTPS에서는 SSL과 TLS 라는 두 개의 프로토콜 사용

 

HTTPS 문제점

• SSL 사용하면 처리가 늦어짐
• HTTPS는 서버, 클라이언트 모두 암호화와 복호화 처리가 필요. CPU나 메모리 등의 하드웨어 리소스를 소비
• HTTP통신에 비해 SSL 통신만큼 네트워크 리소스를 더 소비, SSL 통신만큼 통신 처리에 시간이 걸림
• HTTPS는 HTTP에 비해서 속도가 2~100배 느리다