HTTP 에 보안을 더한 HTTPS

해당글은 그림으로 배우는 HTTP & Network 책의 7장 내용의 일부를 요약한 내용입니다.

 

---

 

HTTPS 는 HTTP 프로토콜에 암호화, 인증, 완전성 보호를 더하기 위해 사용하는 프로토콜이다.

 

1. HTTP 에 암호화와 인증과 완전성 보호를 더한 HTTPS

---

HTTP 통신은 암호화되지 않은 평문으로 실시된다. 예를 들면 웹 페이지에서 신용 카드 번호를 입력했을 때 통신이 도청되면 신용 카드 번호를 도청하게 된다.

또한 HTTP 에는 통신 상대의 서버나 클라이언트를 인증하는 수단이 없다. 따라서, 실제로 의도한 통신 상대와 통신하고 있지 않을 가능성과 수신한 메시지가 도중에 변조되어 있을 가능성이 있다.

 

이러한 문제를 해결하기 위해서는 암호화와 인증과 완전성 보호 같은 구조를 HTTP 에 추가할 필요가 있다. 이를 HTTPS 라고 부른다.

 

 

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

---

HTTPS 는 완전히 새로운 어플리케이션 계층의 프로토콜은 아니고 HTTP 통신을 하는 소켓 부분만 SSL 이나 TLS 프로토콜로 대체한 방식이다.

보통 HTTP 는 직접 TCP 와 통신하지만 SSL 을 사용한 경우에는 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신하게 된다. 즉, SSL 이라는 껍질을 덮어쓴 HTTP 가 HTTPS 인 것이다. SSL 은 현재 세계 어느 곳에서도 널리 사용되고 있는 네트워크 보안 기술이다.

 

출처 - 그림으로 배우는 HTTP & Network

 

 

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

---

공통키 암호의 딜레마

• 암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 부른다
• 키를 서로 공유하고 있어야만 하기 떄문에 키를 전달할때 통신이 도청되거나 안전하게 보관하지 못한 경우 문제가 된다

 

두 개의 키를 사용하는 공개키 암호

• 공통키 암호의 문제를 해결하려고 한 것이 공개키 암호 방식으로 비밀키와 공개키를 페어로 사용한다
• 보내는 측이 상대의 공개키를 사용해 암호화하고 수신자는 자신의 비밀키를 사용해 복호화한다
• 이 방식은 암호를 푸는 비밀키를 공유할 필요가 없어 키가 유출될 걱정을 할 필요가 없다

 

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

• HTTP 는 공통키 암호와 공개키 암호 둘다 사용하는 하이브리드 암호 시스템이다
• 공개키 암호는 공통키 암호보다 처리가 느리기 때문에 모든 통신에 공개키 암호를 사용하는 것은 비효율적이다
• 두 가지 암호의 장점을 살릴 수 있도록 임시로 생성한 공통키를 공개키를 이용해 교환하고 메시지는 공통키로 암호화하는 방식이다

 

 

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

---

공개키 암호에도 공개키가 진짜인지 아닌지를 증명할 수 없다는 문제가 있다. 예를들어, 어떤 서버와 공개키 암호를 사용해서 통신을 시작하려 할 때 도중에 공격자가 공개키를 바꿔치기 했을지도 모른다. 이 문제를 해결하는 데는 인증 기관(CA: Certificae Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있다. (VeriSign 등)

 

인증 기관이 이용되는 방법

인증 기관의 공개키가 내장된 브라우저

• 인증 기관의 공개키는 항상 보장되어야 하기 때문에 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 출시된다

공개키 인증서 발급 과정

• 서버 운영자가 인증 기관에 공개키를 제출
• 인증 기관은 제출된 공개키에 디지털 서명을 하고 서명이 끝난 공개키를 생성
• 서버 운영자는 서버에 인증서를 등록

서버 클라이언트 통신 과정

• 서버는 작성된 공개키 인증서를 클라이언트에 보냄
• 클라이언트는 서버의 공개키가 신뢰할 수 있는 것인지 확인한다
  • 인증 기관의 공개키로 서버의 공개키의 서명을 복호화 후 복호화 데이터를 검증
  • 만약, 복호화가 실패하거나 복호화 데이터가 인증서 정보와 다를 경우 신뢰할 수 없다고 판단
• 클라이언트는 서버의 공개키를 이용해 메시지 전송 시작

 

조직의 실제성을 증명하는 EV SSL 증명서

• EV(Extended Validation) SSL 증명서는 실제로 존재하는 기업인지를 확인하는 역할이 가능하다
• 세계 표준의 인정 가이드라인에 의해서 발행되며 엄격하게 관리되기 때문에 증명서로 웹사이트의 신뢰성을 더욱 더 높일 수 있다
• 브라우저의 주소창의 색이 녹색으로 변하거나 인증서 표시되는 발급 대상으로 EV SSL 증명서가 적용되었는지 확인 가능하다
• 피싱 사기 방지를 의도한 것이지만 보통 유저들이 EV SSL 증명서에 대해 알지 못하기 때문에 그 효과에 대해서는 의문이 있다는 의견도 있다

 

크롬브라우저에서는 자물쇠 아이콘을 클릭 시 표시되는 발급 대상으로 EV SSL 인증서인지 확인 가능하다

참고로 실제 EV SSL 이 얼마나 사용되는지 궁금하여 확인해본 결과 구글, 유튜브, 아마존, 페이스북, 트위터, 바이두, 야후, 네이버 등 일반 사이트에서는 사용되지 않았으나 뱅크오브아메리카, 아메리칸익스프레스, 페이팔, 국민은행, 우리은행 등의 금융 관련 사이트에는 모두 사용중인걸로 확인했다. 아마도 금융 관련 웹사이트에서는 통상적으로 적용하고 있는 듯 하다.

 

 

인증 기관은 신용이 제일

• SSL 은 인증 기관을 신용할 수 있다는 전제로 이루어져 있다
• 2011년 7월에는 네델란드의 DigiNotar 라는 인증 기관을 통해 구글이나 트위터 등의 가짜 증명서가 발행되는 SSL 신뢰의 근본이 흔들리는 사건이 발생하기도 했다
  • 해당 기관은 보안 위반으로 해킹 공격을 받아 인증서 사기 발급에 이용되어 결국 파산했다 한다
  • 관련 위키 참고 - https://en.wikipedia.org/wiki/DigiNotar (Hacking in the 2010s )
• 이렇게 인증 기관의 서명이 있는 인증서로 서버로 위장할 때에 사용되면 유저는 알기 어렵다
• 증명서를 무효화하는 증명서 취소 리스트(CRL) 구조나 루트 인증 기관을 브라우저에서 삭제하는 대책이 있지만 모두 효과를 발휘할 때까지 시간이 걸리는 문제가 있다

 

자기 인증 기관 발행 증명서는 '나야 나' 증명서

• OpenSSL 등의 소프트웨어를 사용하면 누구든지 인증 기관을 구축해 서버 증명서를 발행할 수 있다
• 그러나 이 서버 증명서는 인터넷 상에서는 증명서로 구실을 하지 못하며 쓸모가 없다
• 독자적으로 구축한 인증 기관을 자기 인증 기관이라 부르고, 거기서 발행한 쓸모 없는 증명서를 비하해서 '나야 나 증명서' 라고 부른다
• 이런 증명서를 사용하더라도 SSL 로 암호화하고 있어 통신은 안전하다는 설명은 잘못된 것이다. 위장하고 있는 가짜 서버와 통신하고 있을 가능성이 있기 때문이다

 

마이너 인증 기관을 사용하면 '나야 나' 증명서가 될 수도 있다

• 일부 브라우저에만 포함된 마이너 인증 기관도 존재한다
• 그러한 인증 기관이 발행한 증명서는 어떤 브라우저에서 정규 증명서로 취급되더라도 다른 브라우저에서는 '나야 나' 증명서로 취급될 수 있다

 

 

5. 안전한 통신을 하는 HTTPS 의 구조

---

책의 통신 수순에 대한 자세한 설명은 생략한다

• 자세한 내용을 공부하고 싶다면 생활코딩을 추천 (opentutorials.org/course/228/4894)

 

SSL 은 느리다?

• SSL 통신이 지연되는 이유에는 두가지가 있다
• 첫번째. 통신 속도가 떨어지는 것
  • 네트워크 부하는 HTTP 를 사용하는 경우에 비해 2배에서 100배 정도 느려질 수 있다
  • SSL 에 필요한 통신이 추가되기 때문에 전체적으로 처리해야할 통신이 증가한다
• 두번째. CPU 나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려지는 것
  
  • 서버나 클라이언트에서는 암복호 처리를 위한 계산을 위한 리소스를 추가로 소비하게 된다
• HTTPS 를 항상 사용하지 않고 보안이 필요한 부분에만 적용하여 리소스를 절약하기도 하고, 증명서 구입 비용이 부담되는 서비스나 개인적인 웹 사이트에서는 HTTP 만 선택하는 경우도 있다 (최근엔 일부 서비스에만 HTTPS 를 적용하는 경우는 찾아보기 힘듬)

---