[Network] HTTP와 HTTPS, TLS (Transport Layer Security)

0. TLS, SSL

 TCP/IP 네트워크 통신에서 보안을 제공하기 위한 암호 규약을 의미한다. (TLS가 SSL의 후속 버전이며, 둘 다 암호화된 통신을 제공하기 위한 프로토콜이라는 점에서 혼용되어 사용되기도 한다.)

 

HTTP 2.x 이상의 버전들은 HTTPS 사용을 강하게 권장하고 있다고 알고 있는데, HTTPS 사용을 위해서는 응용 계층과 전송 계층 사이에서 TLS/SSL이라는 독자적인 프로토콜을 이용한다. (반드시 TLS/SSL을 사용해야 하는것은 아니고, HTTPS를 위한 보안 프로토콜로 보편적으로 많이 사용하는 프토로콜이 TLS/SSL이다)

 

 

 

1. Symmetric Cryptography (대칭 암호화)

 sender와 receiver가 secure한 통신을 하기 위해서, 모든 네트워크 사용자 각각이 고유한 secret key를 가지고 암호화-복호화의 과정을 거치는 방법이다. key를 이용한 암호화라면 가장 먼저 생각나는 간단한 방법이지만, sender와 receiver가 같은 키를 사용하므로 attacker가 통신 과정에서 secret key를 얻는다면 손쉽게 데이터를 복호화하여 얻을 수 있으므로 해킹에 취약하다. 또한 네트워크상에 N명의 사용자가 있다면, 각 사용자는 통신을 위해서 다른 N-1명의 secret key를 갖고 있어야 하고, 따라서 서버 전체에는 N(N-1)/2개의 secret key가 존재해야 하므로 key를 관리하는 것이 쉽지 않게 된다.

 

symmetric cryptography

 

 

 

 

 

2. Asymmetric Cryptography (비대칭 암호화)

 대칭 암호화 방법과 다르게, sender는 공개되어 있는 public key를 이용해서 암호화하고, receiver는 고유의 private key를 이용하여 복호화하는 방법이다. private key와 public key는 상호간 동일한 역할을 한다. A의 public key를 이용하여 암호화된 데이터는 A의 private key로만 복호화가 가능하며, private key로 암호화해도 public key로 복호화 가능하다. 이 때 일반적으로 private key로 잠그는것을 서명(public key로 복호화 가능), public key로 잠그는것을 암호화(private key로만 복호화 가능)라고 하며 그 목적성에 차이가 있다.

 

sender A가 receiver B에게 암호화된 데이터를 전송하려 한다고 하자. 먼저 B가 자신의 public key를 A에게 알려주면, A는 받은 public key를 이용해서 데이터를 암호화한다. 그 후에 암호화된 데이터를 B에게 전송하면, B는 private key를 이용해서 받은 데이터를 복호화한다. 대칭 암호화 방식과는 다르게, 해커가 통신 과정에서 B의 public key나 암호화된 데이터를 탈취한다고 해도 그것만 가지고는 데이터를 해석할 수 없다. 복호화를 위해서는 통신에 사용된 public key에 대응하는 private key도 가지고 있어야 하는데, private key는 통신에 사용되지 않기 때문에 직접 서버를 해킹하지 않고는 해킹이 불가능해진다.

 

(public key를 자물쇠를 채우는 과정으로, private key를 열쇠로 생각하면 이해가 쉽다.)

 

 그런데 어떻게하면 public key와 private key가 다른데 암호화된것을 복호화 할 수 있을까? 가장 널리 사용되고 있는 RSA는 큰 수를 소인수분해하는 time cost가 매우 크다는 점을 이용하여 암호화한다. (이 방법이 궁금하면 구글링하자)

 

asymmetric cryptography

실제 TLS에서는 대칭키를 서로 공유하는 통신을 비대칭 암호화방식으로, 실제 통신은 대칭키 방식을 이용함으로서 RSA로 인해서 과도한 프로세서 리소스의 소비가 일어나는 것을 방지한다.

 

 

 

 

3. CA와 SSL인증서

 암호화 방식으로 통신하면 통신이 이루어지는 데이터들만을 이용해서는 데이터 복호화하는것이 불가능하다. 그런데 이러한 암호화 방식으로만 통신하면, 서버가 신뢰할 수 있는 서버인지를 알기 어렵다. 따라서 통신하는 서버가 신뢰할 수 있는 서버인지를 알기 위해서 인증서를 사용한다.

이러한 인증서를 발급해주는 기관이 바로 CA이다. safe한 TLS 통신을 위해서는 CA를 통해서 인증서를 발급받아야 한다. CA 또한 자체적으로 private key와 public key를 이용하여 인증을 돕는다.

 

먼저 인증서를 발급받기 위해서는

 

1. 서버는 사이트의 정보(hostname)와 public key를 CA에 제공한다.
2. CA는 검증을 거친 후 받은 hostname, public key등을 해싱하고 그 결과들을 CA의 private key로 암호화하는 디지털 서명 과정을 거쳐 인증서를 만들어준다.

 

브라우징을 하다보면 '신뢰할 수 없는 사이트'라고 안내가 뜨는 사이트들이 있는데, 이러한 사이트는 CA에 의해 공인된 인증서가 아니기때문에 이러한 안내가 뜨는 것이다.

 

이제 클라이언트가 서버와 신뢰할 수 있는 통신을 하려면, handshaking 과정을 통해서 연결한 후에, 서버는 CA에서 발급받은 인증서를 클라이언트에 전달한다. 그러면 클라이언트는

 

1. 인증서가 유효한 CA에서 발급받은 인증서인지 확인한다.
2. 맞다면, 해당 CA기관의 public key로 인증서의 디지털 서명을 복호화한다. -> hostname, public key등의 해싱값을 구할 수 있다.
3. 구한 public key의 해싱값과 서버의 public key를 직접 해싱한 결과가 같다면 공인된 인증서이다.

앞서 private key로 잠그는 과정을 '서명'이라고 했는데, CA의 private key로 암호화하면 누구나 public key로 복호화할 수 있으며, 이는 곧 CA의 private key가 사용되었는지 (=CA의 인증이 되었는지)를 확인할 수 있게 한다.

 

이러한 과정을 통해 클라이언트는 해당 서버가 CA에서 공인된 인증서를 가진 믿을 수 있는 서버임을 확인할 수 있다. 그 후에는 위에서 언급했듯이 비대칭/대칭키를 혼합한 통신을 이용하여 신뢰할 수 있는 통신을 할 수 있게 된다.

 

> q. 만약 해커가 서버가 CA에서 받은 인증서를 탈취한다면, 서버의 public key는 공개되어 있기 때문에 서버인 척하고 클라이언트에게 서버의 인증서를 보내면? 서버인 척이 불가능하려나?

-> 해커가 진짜 서버인척하는게 가능하다면 문제가 생길수 있을거같음. 해커 서버의 public key를 client가 가져온다면 문제가 안생기겠지. 해커가 완벽하게 진짜 서버인척해서 client가 진짜 서버의 public key를 가져오는 상황이 되면 문제가 생길거고,,

위의 예시 - MITM 해킹 : https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=jwk123&logNo=100163674151

 

마지막으로, 인증서를 작성하는 기관마다 양식이 상이하면 인증서를 분석하기 쉽지 않기 때문에, 모든 인증서는 X.509라는 표준을 기반으로 구성된다. 

 

 

 

X.509의 양식은 크게 버전, 고유 일련번호, 발급자 서명, 발급자 정보, 유효기간, 소유자 정보, 소유자 공개키 정보, 발급자 공개키 identifier, 소유자 공개키 identifier 등의 정보가 들어간다. (버전에 따라서 상이하다)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. 추가로..

 TLS는 애플리케이션 계층과 전송계층 사이에 위치하기 때문에, IP주소와 port번호, dns와 같은 하위 계층의 정보들은 암호화할 수 없다. 이와 같은 정보들도 보호하려면 TOR를 사용하면 된다.