HTTPS, SSL 인증서

- HTTP(Hypertext Transfer Protocol)

: 웹환경에서 클라이언트(브라우저)와 서버(웹서버)가 통신하기 위한 프로토콜(규약, 약속)

: 인터넷상에서 정보를 주고 받기 위한 프로토콜

​

HTTP 프로토콜의 단점 : 브라우저와 웹서버간의 데이터가 암호화되지않아 평문으로 전달된다.

​

그래서 나온게

​

- HTTPS (Hypertext Transfer Protocol Secure)

: 보안이 강화된 HTTP, 통신하는 모든 데이터가 암호화되어 전달된다.

: HTTP 프로토콜에 SSL(Secure Socket Layer)을 사용한다.

​

​

* SSL(Secure Socket Layer)

: SSL과 TLS는 보안계층이라는 독립적인 프로토콜 계층을 만들어 응용계층과 전송계층 사이에 속하게 된다.

: 웹서버(서버)와 브라우저(클라이언트) 사이의 보안을 위해 만들었다.

: 비대칭키(개인키, 공개키) 암호화 방식

: 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서이다.

​

* SSL 인증서 역할

1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.

2. SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

​

* Root CA

: SSL 인증서는 제일 위에 존재하는 Root 인증서, 중간에 존재하는 중간 인증서, 그리고 우리가 서버에 적용하기 위한 서버 인증서(SSL 인증서)가 있다.

: 글로벌 인증기관에서 배포하는 Root 인증서

​

- Root 인증서

: CA에서 자체 서명한 Self-signed 인증서, 공개키 기반 암호화를 사용한다.

​

- 중간 인증서

: Root 인증서와 서버 인증서 사이에 존재하여 위험을 완화하도록 만들어진 중간인증서

: 가장 많은 권한을 갖는 Root 인증서의 손상을 대비?

​

- SSL 인증서

: 우리가 흔히 요청하는 서버 인증서

​

​

​

​

* CA(Certificate authority)

: 인증서의 역할은 클라이언트가 접속한 서버가 신뢰할수 있는 서버가 맞는지 보장하는 역할

이러한 역할을 하는 민간기업들이 있는데 이런 기업들을 CA 혹은 Root certificate 라고 부른다.

CA는 아무기업이나 할 수 있는것이 아니고 신뢰성이 엄격하게 공인된 기업들만이 참여할수 있다.

- Symantec

- comodo

- GoDaddy

- GlobalSign

​

SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야한다.

​

​

* SSL 인증서의 내용

SSL 인증서에는 다음과 같은 정보가 포함되어있다.

​

1. 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인)

2. 서버측 공개키 (공개키의 내용, 공개키의 암호화 방법)

​

인증서의 내용은 크게 2가지로 나누어진다.

1번은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지에 대한 내용을 담고있고, 2번은 서버와 통신을 할때 사용할 공개키와 그 공개키의 암호화 방법들의 정보를 담고있다.

서비스의 도메인, 공개키와 같은 정보는 서비스가 CA로부터 인증서를 구입할때 제출한다.

​

위와 같은 내용은 CA에 의해서 암호화된다. 이때 사용하는 암호화 기법은 공개키 암호화 방식이다. CA는 CA의 비공개키(개인키)를 이용해서 서버가 제출한 인증서를 암호화 한다. CA의 비공개키는 절대로 유출되어서는 안된다.

​

* SSL Handshaking

1. 클라이언트가 서버에게 "Client Hello" 메시지를 전송한다.

​

- 메시지 내용

1-1) SSL/TLS version

1-2) SSL 통신에 사용할 암호 알고리즘

1-3) 데이터 압축 방법 (ex Gzip)

​

​

2. 서버가 클라이언트에게 "Server Hello" 메시지를 전송한다.

​

- 메시지 내용

2-1) 클라이언트가 요청한 암호 알고리즘의 대한 동의

2-2) 서버에서 생성한 SessionID

2-3) 서버의 Digital Certificate (디지털 인증서)

2-4) 서버의 Public Key(공개키)

​

3. 클라이언트는 서버에서 온 Digital Certificate(디지털 인증서) 를 확인해 신뢰할 수 있는 서버인지 확인

클라이언트는 서버가 보내온 Digital Certifcate(디지털 인증서)를 공인 CA에 확인한다.

이후 정상적으로 서버가 신뢰하다고 판단되면 다음단계 진행

​

- 공인 CA(인증기관) 에서 제공한 공개키로 서버의 디지털 인증서를 복호화 한다.

* 서버의 디지털인증서는 공인 CA(인증기관)의 개인키로 암호화되어 있기 때문에 공인 CA에서 제공해준

공개키로 복호화 할수있다.

* 서버는 공인 CA에서 인증서를 발급할때 서버의 공개키와 함께 인증서를 암호화 한다.

그러므로 공인 CA의 공개키로 복호화했을경우 서버의 공개키가 포함되어있다.

​

4. 클라이언트는 서버와 통신에 사용할 대칭키를 서버의 공개키로 암호화하여 전송한다.

* 공인 CA의 공개키로 복호화한 인증서에는 서버의 공개키가 포함되어있다.

* 서버의 공개키로 통신할때 사용할 대칭키를 암호화 하여 전송한다.

​

​

* SSL 암/복호화 하는 과정을 다른서버(Proxy Server)가 대신하게 만든다.

​

​

*******한눈에 알아보기

- SITE(내 서버 URL)

1. SITE의 정보와 SITE의 공개키를 인증기관에게 전달한다.

2. 인증기관(CA)은 전달받은 SITE의 정보와 공개키를 검증하여 인증기관(CA)의 개인키로 암호화하여 인증서를 제작한다.

3. 클라이언트는 SITE에 접근했을때 미리 브라우저에서는 공인 인증기관(CA)의 목록을 가지고 있다.

4. 클라이언트는(브라우저)는 SITE에게 접속요청을 보낸다.

5. SITE는 인증기관(CA)로부터 발급받은 인증서를 클라이언트에게 전달한다.

6. 인증기관(CA)으로부터 전달받은 공개키로 SITE의 인증서를 복호화하여 SITE의 정보와 SITE의 공개키를 얻는다.

7. 획득한 SITE의 공개키로 SITE와 주고받아야할 데이터를 암/복호화할 대칭키를 암호화 하여 전달한다.

8. SITE는 암호화된 대칭키를 전달받아 SITE의 개인키로 복호화를 하여 대칭키를 얻는다.

(인증서에 SITE의 공개키가 있었으며, 클라이언트는 해당 공개키로 대칭키를 암호화 했으므로 SITE의 개인키로 복호화 가능)

9. 안전하게 전달받은 대칭키로 클라이언트와 SITE는 암호문을 주고받는다.