[컴퓨터 네트워크] HTTPS

HTTPS

. HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있다. 이러한 보안 취약점을 해결하기 위한 프로토콜이 HTTP에 S(Secure Socket)가 추가된 HTTPS

 

HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화됨

 

 

 

SSL / TLS

컴퓨터 네트워크 상에서 보안 통신을 제공하기 위해 설계된 프로토콜

SSL과 TLS은 같은 것이라 볼 수 있음

SSL은 TLS의 과거 명칭

SSL은 TCP/IP 암호화 통신에 사용되는 규약으로써 넷스케이프에서 만들었으며, SSL 3.0 버전에서부터 IETF에서 표준으로 정해서 TLS 1.0이 되었음. 하지만 보통 SSL로 많이 불려짐

즉, TLS 안에 SSL이 속함

 

 

 

 

 

공개키 방식

두개의 키를 이용하여 암호화하는 방식

A키로 암호화하면 B키로 복호화할 수 있음

B키로 암호화하면 A키로 복호화할 수 있음

둘 중 하나를 개인키(비공개키)라 하며 이는 자신만 가지고 있고 공개되지 않음

나머지 하나를 공개키라 하며 이는 타인에게 제공함

 

공개키가 유출되더라도 비공개키를 모르기에 안전

 

 

대칭키 방식

동일한 키로 암호화, 복호화가 가능

대칭키는 매번 랜덤으로 생성되어 누출되어도 다음에 사용할 때는 다른키가 사용되기 때문에 안전

공개키보다 빠르게 통신 가능

 

 

 

 

전자서명

 서명자를 확인하고 서명자가 했다는 사실을 나타내는데 이용하려고 특정 전자문서에 첨부되거나 논리적으로 결합된 전자적 형태의 정보

 

→ 말그대로 서명하는것 / 서명을 통해서 서명한 사람을 확인하는 용도로 사용하는 것

→ 공개키 암호를 이용하면 통신간의 인증 및 변조 검증이 가능

 

 

전자 서명은 해싱→서명→검증 세가지의 기본 단계로 나뉜다.

1. 정보를 해싱한다.
   • 정보 해싱은 필수적인 부분은 아니다.
2. 해시된 정보에 메시지 발신자의 서명을 작성한다(공개키로 암호화 된다).
   • 이때의 서명에서 개인 키가 포함되지 않는 경우, 메시지 수신자는 유효성을 검증하기 위해 상응하는 공개 키를 사용할 수 없다. 공개키와 개인키는 모두 메시지 발신자에 의해 생성되야하고, 수신자에게는 공개키만 공유된다.
3. 메시지 수신자는 발신자가 제공한 공개키를 통해 디지털 서명의 유효성을 확인할 수 있다.
   • 이는 발신자만이 공개키에 상응하는 개인키를 가지고 있기 때문이다.

 

 

 

HTTPS 동작 방식

HTTPS는 대칭키 방식과 공개키 방식을 함께 사용함

실제 데이터를 암호화할 때는 비교적 빠른 대칭키 방식을 사용

서버에 대한 인증과 안전한 대칭키 전달에는 공개키 방식을 많이 사용

 

 

서버와 브라우저 간의 HTTPS 통신 과정은 크게 두 가지 과정으로 나누어 생각해볼 수 있음

• 인증: 서버가 진짜 내가 요청한 서버가 맞는지 확인
• 협상: 브라우저와 서버가 어떤 암호화 방식을 사용할 것인지 협의

 

 

 

인증 - CA

인증과정은 CA라는 신뢰할 수 있는 외부 인증 기관을 거쳐서 진행

 

CA는 해당 서버가 믿을 만한 서버라는 것을 증명하는 SSL 인증서를 발급함

 

브라우저는 서버로부터 받은 인증서가 해당 CA에서 발급한 것이 맞는 지를 확인하여, 믿을 수 있는 서버인지 검증할 수 있음

 

SSL 인증서
CA에서는 검증된 서버에 대한 인증서를 발급하는데, 이를 SSL 인증서 혹은 TLS 인증서라고 부른다. SSL/TLS는 보안을 제공하는 프로토콜인데, 이 인증서를 생성하는 데 직접적인 연관이 있는 것은 아니다. "SSL/TLS와 함께 사용할 인증서”라는 의미가 조금 더 정확하다.

 

 

 

인증서 발급

1. 서버는 공개키와 개인키를 생성하여, 자신에 대한 정보와 함께 공개키를 전달한다.
2. CA는 전달 받은 정보를 바탕으로 신뢰할 수 있는 서버인지 확인하고, 서버의 공개키를 담은 SSL 인증서를 생성한다.
3. SSL 인증서는 CA의 개인키를 통해 암호화한다. 즉, 전자 서명을 통해 해당 CA에서 발급한 인증서라는 것 증명할 수 있게 한다.
4. 암호화된 SSL 인증서를 서버에 전달하고, 서버는 이를 보관한다.

 

 

인증서 검증

 

1. 브라우저가 서버와 연결을 요청하면, 서버는 자신의 SSL 인증서를 브라우저에게 전달한다.
   1. SSL 인증서는 SSL Handshake 과정을 통해서 브라우저에게 전달된다.
2. 브라우저는 CA에게 인증서 검증 요청을 한다.
   1. 브라우저에는 주요 인증 기관의 리스트와 공개키를 이미 보유하고 있다. 따라서 매번 인증 기관에서 인증서 검증 요청할 필요가 없다.
   2. 브라우저의 인증 기관 리스트 중에 인증서를 발급한 기관이 없다면, 외부 인터넷에서 인증 기관과 공개키에 대한 정보를 찾는다.
3. CA는 자신의 공개키를 브라우저에게 전달한다.
4. 브라우저는 CA 공개키로 SSL 인증서를 복호화한다. 복호화가 된다면 서버의 공개키를 확보한다.

 

 

 

 

SSL Handshake

 

신뢰할 수 있는 서버임이 인증되었다면, 서버와 브라우저가 서로 어떤 알고리즘과 대칭키로 데이터를 암호화하여 주고받을 지 협상이 필요함.

이 과정은 전송계층인 TCP연결이 수립된 후 SSL/TLS 프로토콜에서 SSL Handshake를 통해 셜정됨

 

 

SSL Handshake은 데이터를 실제로 암호화 하기 위한 대칭키를 전달하는 것이 가장 큰 목적

 

• 데이터 암호화 알고리즘(Cipher Suite) 결정
• 데이터를 암호화 할 대칭키 전달

 

1. Client Hello: 가능한 암호화 알고리즘 목록을 서버에게 전달한다.
2. Server Hello: 서버는 알고리즘 목록 중 하나를 선택한다.
3. Certificate: 서버가 자신의 SSL 인증서를 클라이언트에게 보낸다.
   1. 이후 클라이언트는 SSL 인증서를 검증하는 과정을 거쳐, 서버의 공개키를 획득한다.
4. (Optional) Server Key Exchange: SSL 인증서에 서버의 공개키가 없는 경우, 서버가 직접 전달한다.
   1. 키 교환 알고리즘이 공개키 방식이 아니라면 인증서 안에 공개키가 들어있지 않다. 이 경우 서버에서 키 교환에 필요한 다른 값을 서버에서 직접 전달한다.
   2. Diffie-Hellman(DH) 알고리즘은 공개된 특정 값을 통해 대칭키를 계산하기 때문에, 이 값을 Server Key Exchange 과정에서 전달한다.
5. Server Hello Done: 서버의 작업이 종료되었다.
6. Client Key Exchange: 클라이언트가 대칭키(데이터를 실제로 암호화 할 키)를 생성하여, SSL 인증서에 있던 서버의 공개키로 암호화하여 전달한다.
   1. 공개키가 없는 경우는 클라이언트에서 서버가 대칭키를 계산할 수 있는 특정 값을 전달한다.
7. ChangeCipherSpec: 클라이언트와 서버가 교환할 정보를 패킷으로 전달한다.
   1. 서버는 클라이언트가 보낸 대칭키를 서버의 개인키로 복호화 해 대칭키를 얻는다.
8. Finished: SSL Handshake를 종료한다.

 

 

 

 

 

 

 

 

 

#참고자료

https://velog.io/@ann0905/HTTPS-2.-HTTPS%EC%99%80-SSL-Handshake

[Network] HTTPS와 SSL Handshake

https://velog.io/@ann0905/HTTPS-2.-HTTPS%EC%99%80-SSL-Handshake

[Network] HTTPS와 SSL Handshake