HTTPS의 세부사항

최근 인증서 관련 이슈를 만난적이 있었는데, 이번 장을 통해서 조금이나마 이해가 될 수 있게 되었다 :)

• 2. HTTPS는 HTTP의 가장 유명한 보안 버전이다.
• 2. HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.
• 2. HTTPS는 웹 기반 전자상거래의 고속 성장을 이끄는 주력이다.

HTTPS 세부사항

• 2. HTTPS는 그냥 보안 전송 계층을 통해 전송되는 HTTP이다.
• 2. HTTPS는 HTTP 메세지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안계층으로 보낸다.
• 오늘날 HTTPS의 보안계층은 SSL과 TLS로 구현되었다.

1. HTTPS 스킴

• 보안 HTTP는 선택적이다.
• 웹 서버로의 요청을 만들때, 웹서버에게 HTTP의 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요하다.
• 이것은 URL의 스킴을 통해 이루어진다.

https://feel5ny.github.io

• 만약 URL이 http 스킴을 갖고 있다면 클라는 서버에 80번 포트로 연결하고 평범한 HTTP 명령을 전송한다.
• 만약 URL이 https 스킴을 갖고 있다면 클라는 서버에 443번 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고, 암호화된 HTTP 명령이 뒤를 잇는다.
• SSL 트래픽은 바이너리 프로토콜이기 때문에 HTTP와는 완전히 다르다.
  • 그 트래픽은 다른 포트로 전달된다.(SSL은 보통 443포트)

2. 보안 전송 셋업

HTTP

HTTP에서는 클라는

1. 웹서버의 80번 포트로 TCP 커넥션을 열고,
2. 요청메세지를 보내고,
3. 응답메세지를 받고,
4. 커넥션을 닫는다.

HTTPS

HTTPS에서는 클라는

1. 웹서버의 443번 포트로 연결한다. TCP 연결이 되고나면,
2. 클라와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다.
3. 핸드셰이크가 완료되면 SSL 초기화는 완료되며 클라는 요청 메세지를 보안계층에 보낼 수 있다. 이 메세지는 TCP로 보내지기 전에 암호화된다. 암호화된 요청을 보낸다.
4. SSL을 통해 보내진 HTTP 요청 / TCP를 통해 보내진 암호화된 요청
5. SSL 닫힘을 통지한다.
6. TCP 커넥션이 닫힌다.

3. SSL 핸드셰이크

• 암호화된 HTTP 메세지를 보낼 수 있게 되기 전에 클라와 서버는 SSL 핸드셰이크를 할 필요가 있다.
• 핸드셰이크에서 일어나는 일
  1. 프로토콜 버전 번호 교환
  2. 양쪽이 알고 있는 암호 선택
  3. 양쪽의 신원을 인증
  4. 채널을 암호화하기 위한 임시 세션 키 생성
• SSL 핸드셰이크를 단순화한 버전이다.
• SSL이 어떻게 사용되는가에 따라 핸드셰이크는 보다 복잡해질 수 있다.

실제로 좀더 자세히 보면..

출처 

3.1 예시로 알아보기

www.bing.com에  접속할 때 SSL 핸드쉐이크 과정을 와이어 샤크를 보면서 알아보자.

1. (클 => 서버) Client Hello
2. (서버 => 클) Server Hello
3. (서버 => 클) Certificate
4. (서버 => 클) Certificate Status
5. (서버 => 클) Server Key Exchange
6. (서버 => 클) Server Hello Done
7. (클 => 서버) Client Key Exchange
8. (클 => 서버) Change Cipher Spec
9. (클 => 서버) Encrypted Handshake Message
10. (서버 => 클) Change Cipher Spec
11. (서버 => 클) Encrypted Handshake Message

1. (클 => 서버) Client Hello

• 사용자가 bing에 접속하기 위해 bing 서버쪽에 통신을 요청
• TLS 버전,
• 자신이 지원하는 cipher리스트,
• 클라이언트가 생성한 난수 정보를 보낸다.

2. (서버 => 클) Server Hello

• 서버는 자신의 SSL버전
• 자신이 만든 임의의 난수와
• 클라이언트의 cipher 리스트 중 하나의 선택하여 그 정보를 클라이언트에게 보낸다.

3. (서버 => 클) Certificate

• 서버는 자신이 갖고있는 인증서정보를 전송한다.
• 첫번째는 서버의 인증서 이고 두번째는 CA 인증서이다.

4. (서버 => 클) Certificate Status

• 갖고있는 인증서의 유효성 정보를를 전송한다.
• OCSP는 온라인 인증서 상태 프로토콜의 약자로, 인증서 유효성 확인을 제공하는 방법이다.

5. (서버 => 클) Server Key Exchange

• 서버는 ECDHE 키 쌍을 만들어서 클라에게 public 키를 전송한다.
• 이 키는 클라의 public키를 이용해서 ECDHE shared secret을 만들기 위해 사용된다.

  ECDHE : Elliptic Curve 및 Ephermeral 을 지원하는 디피 헬만 (Diffie Hellman) 방식 (PFS, Perfect Foward Secrecy 지원) 출처 

6. (서버 => 클) Server Hello Done

• 서버의 말이 끝남

7. (클 => 서버) Client Key Exchange

• 클라는 자신이 마든 난수와 + 서버가 만든 난수를 통해 = pre-master-secret을 생성한다.
• 서버의 공개키를 통해 암호화하여 서버로 전송한다. (아까 5번에서 받은 public key)
• 즉, 해당과정을 통해 실질적으로 암호화에 사용하는 대칭키가 생성된다.

8. (클 => 서버) Change Cipher Spec

• 클라이언트가 성공적으로 공유키를 생성했으며, 이후 메시지는 암호화 하여 전송할 것을 알리는 메시지를 전송한다.

9. (클 => 서버) Encrypted Handshake Message(Finished)

• 클라이언트는 서버에게 핸드셰이크가 성공적으로 완료되었음을 알린다.

10. (서버 => 클) Change Cipher Spec

• 서버도 성공적으로 공유키를 생성했음을 알린다.

11. (서버 => 클) Encrypted Handshake Message(Finished)

• 서버도 클라에언트에게 핸드셰이크가 성공적으로 완료되었음을 알린다.

12. 어플리케이션 데이터

• 서로 상대방에게 전송할 데이터를 암호화하여 전송한다.

4. 서버 인증서

• SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서다.
• SSL은 서버 인증서를 클라로 나르고 다시 클라 인증서를 서버로 날라주는 상호 인증을 지원한다.
  • 오늘날 클라 인증서는 흔히 쓰이지 않는다.
• 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
• 서버 인증서는 X.509 v3에서 파생되 인증서이다. 디지털 인증서 

5. 사이트 인증서 검사

• SSL 자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지 않지만, 최신 웹브라우저들 대부분은 인증서에 대해 간단하게 기본적인 검사를 하고 그 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다.
• 넷스케이프가 제안한 웹 서버 인증서 검사를 위한 한 알고리즘 수행 단계는 다음과 같다.
  1. 날짜 검사
  2. 서명자 신뢰도 검사
  3. 서명 검사
  4. 사이트 신원 검사

1. 날짜 검사

• 브라우저는. 인증서가 여전히 유효함을 확인하기 위해 인증서의 시작 및 종료일을 검사한다.
• 만료되었거나 활성화되지 않았다면 인증서 검사는 실패. 브라우저는 에러를 보여준다.

2. 서명자 신뢰도 검사

• 모든 인증서는 서버를 보증하는 어떤 인증기관에 의해 서명되어 있다. CA = Certificate Authority
• 여러가지 수준의 인증서가 있는데, 각각은 다른 수준의 배경 검증을 요구한다.
  • 전자상거래 서버 인증서를 발급받고자 한다면, 사업체로서의 법인에 대한 법적 증명을 제시해야 한다.
• 누구나 인증서를 생성할 수 있지만 몇몇 CA는 인증서 지원자의 신원 및 사업의 선량함을 입증하는 알기쉬운 절차를 갖춘 잘 알려진 기관이다.
• 이러한 이유료, 브라우저는 신뢰할 만한 서명 기관의 목록을 포함한 채로 배포된다.

  브라우저마다 다르게 셋팅되어있다. 출처 

  • Firefox 
  • Chrome: it uses the certificates included with the OS.
  • Opera : it install the most uses CA within installing the application, you can find the rest in the online root repository
  • iOs 

• 만약 브라우저가 알려져 있지 않은 인증기관으로부터 서명된 인증서를 받았다면 브라우저는 보통 경고를 보여준다.
• 브라우저는 신뢰할만한 CA가 간접적으로 서명한 인증서를 받아들이는 것을 선택할 수 있다
  • 신뢰할만한 CA가 ‘필오의 개발일지’를 위한 인증서에 서명을 하고 필요의 개발일지는 어떤 사이트 인증서에 서명을 한다면, 브라우저는 그 인증서를 올바른 CA 경로에서 파생된 것으로 보고 받아들일 수 있다.

3. 서명 검사

• 한번 서명 기관이 믿을 만하다고 판단되면, 브라우저는 서명기관의 공개키를 서명에 적용하여, 그의 체크섬과 비교해봄으로써 인증서의 무결성을 검사한다.

4. 사이트 신원 검사

• 서버가 누군가 다른 이의 인증서를 복사하거나, 그들의 트래픽을 가로채는 것을 방지하기 위해,

• 대부분의 브라우저는 인증서의 도메인 이름이 대화 중인 서버의 도메인 이름과 비교하여 맞는지 검사한다.

• 서버 인증서에는 보통 단일 도메인 이름이 들어있지만 몇몇 CA는 서버 클러스터나 서버 팜을 위해 서버 이름의 목록이나 서버 이름들에 대한 와일드카드 표현이 들어있는 인증서를 만든다.

  서버 클러스터란? (IT솔루션 by 올파 )

  • 서버 클러스터란 각기 다른 서버(Server Enterprise or server Datacenter)들을 하나로 묶어서 하나의 시스템같이 동작하게 함으로써, 클라이언트들에게 고가용성의 서비스를 제공하는것을 말한다.
  • 클러스터로 묶인 한시스템에 장애가 발생하면, 정보의 제공 포인트는 클러스터로 묶인 다른 정상적인 서버로 이동한다.
  • 서버클러스터는 사용자로 하여금 서버 기반 정보를 지속적이고, 끊기지않게 제공받을수 있게 한다

  서버 팜이란?

  • 서버 클러스터라고 불리기도 하는 서버팜은 컴퓨터 서버와 운영 시설을 한곳에 모아 놓은 곳
  • 허가받지 않은 외부에선 접근이 불가능
  • 임의의 서버가 중단되더라도 다른 서버로 대체되어 원할한 서비스를 제공한다.

  와일드 카드란?

  • 파일을 지정할 때, 구체적인 이름 대신에 여러 파일을 동시에 지정할 목적으로 사용하는 특수 기호. ＊',？' 따위.

• 만약 호스트명이 인증서의 신원과 맞지 않는다면, 사용자를 우선으로 생각하는 클라이언트는 반드시 이 사실을 사용자에게 알리거나 잘못된 인증서 에러와 함께 커넥션을 끊어야 한다.

6. 가상 호스팅과 인증서

잘 모르겠다.

• 가상 호스트(하나의 서버에 여러 호스트명)로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다로운 경우도 많다.
• 만약 사용자가 인증서의 이름과 정확히 맞지 않는 가상 호스트 명에 도착했다면 경고 상자가 나타날 것이다.

HTTPS 예시 (feat. OpenSSL)

• SSL은 복잡한 바이너리 프로토콜이다.
• 가공되지 않은 SSL 트래픽을 직접보는 것은 어렵다.
• 몇가지 SSL 클라이언트와 서버 프로그래밍을 쉽게 만들어주는 상용 혹은 오픈 소스 라이브러리들이 존재한다.

OpenSSL

• OpenSSL은 SSL과 TLS의 가장 인기 있는 오픈 소스 구현이다.
• 2. HTTP://www.openssl.org
• SSLeay도 있다.

온라인 중개소의 홈페이지에 접속했을 때

clients1.online.msdw.com 의 사이트라고 가정

1. SSL 컨텍스트가 초기화 되었다.
2. clients1.online.msdw.com의 IP주소: 63.151.15.11
3. 호스트 clients1.online.msdw.com, 포트 443으로 TCP 커넥션을 열었다.
4. SSL endpoint가 생성되었으며 핸드셰이크 완료
5. 다음의 암호로 SSL 연결이 됨: DES-CBC3-MD5
6. 서버 인증서를 받았다.

대상: /C=US/ST=Utah/L=Salt Lake City/O=Morgan Stanley/OU=Online/CN=clients1.online.msdw.com
발급자: /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority

7. 암호화된 채널을 통해 HTTP 요청을 보냈다.

GET / HTTP/1.0
Host: Clients1.online.msdw.com:443
Connection: close

8. HTTP응답에서 615바이트를 가져왔다.

HTTP/1.1 302 Found
Date: Sat, 09 Mar 2002 09:43:42 GMT
Server: ...
Location: ...
Connection: close
Content-Type: text/html; ...

...

9. 모두 끝났으므로 커넥션을 닫고 정리한다.

프락시를 통한 보안 트래픽 터널링 (HTTPS SSL 터널링 프로토콜)

• 클라는 종종 웹 프락시 서버를 이용한다.

• 그러나 클라가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작했다면, 프락시는 더 이상 HTTP 헤더를 읽을 수 없다.

• 만약 프락시가 HTTP 헤더를 읽을 수 없다면, 요청을 어디로 보내야 하는지 알 수 없게 된다.

• 해결 방법 중에 인기있는 방법은 HTTPS SSL 터널링 프로토콜이다.

• 클라는 먼저 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 말해준다.

• 클라는 이 내용을 프락시가 읽을 수 있도록 암호화가 시작되기 전의 평문으로 말해준다.

• 2. HTTP는 CONNECT 라 불리는 새로운 확장 메서드를 이용해서 평문으로 된 endpoint 정보를 전송하기 위해 사용된다.
  • CONNECT 메서드는 프락시에게 희망하는 호스트와 포트번호로 연결을 해달라고 말해주며 그것이 완료되면 클라와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.

  CONNECT home.netscape.com:443 HTTP/1.0
  User-agent: Mozilla/1.1N
  
  <SSL로 암호화된 데이터가 이 다음에 온다..>

• 클라는 프락시로부터의 응답을 기다릴 것이다.

  • 프락시는 요청을 평가하여 그것이 유효하고, 사용자가 그러한 커넥션을 요청할 수 있도록 허가를 받앗는지 확인한다.
  • 모든 것이 적법하다면 프락시는 목적지 서버로 연결하고 성공하면 200 Connection Established

• HTTP 완벽가이드  책을 보고 이해한 내용을 정리 한 글입니다.

참고자료

• SSL 핸드셰이크1 
• 인증서 
• ocsp 
• SSL 핸드셰이크2 
• ECDHE 
• 생활코딩 - 02. HTTPS와 SSL 인증서 

Related