20200623 https

앞으로 네트워크 카테고리는 사실상 내 메모장이나 다를바가 없을듯하다ㅎㅎ

1. 대칭키

서버와 클라이언트가 통신을 할 때에 그 내용을 암호화할 필요가 있다. 그 때 서버와 클라이언트가 서로 똑같이 가진 대칭키를 통하여 전송 내용을 서로 암호화할 수 있고, 똑같이 대칭키를 통해 그 내용을 복호화할 수 있다. 하지만, 이러한 대칭키를 어떻게 전송하느냐의 문제가 있다. 대칭키를 전송할 때 누가 훔쳐보면 어떡하겠는가?

 

2. public key, private key

https에서 사용되는 방식

서로 쌍을 이루는 private key A, public key B가 있으면 A로 암호화된 값은 B로만 복호화할 수 있으며, B로 암호화된 값은 A로만 암호화할 수 있다. 서버는 private key를 가지고 있고 그와 쌍을 이루는 public key를 공중에 뿌린다. 따라서 원하는 서버가 아닌 피싱 서버에서 보내는 정보를 어차피 우리는 받아들일 수 없게 된다. 

 

그렇다면 클라이언트의 입장에서 공중에 뿌려진 public key가 원하는, 안전한 서버에서 뿌린 public key가 맞는지 확인할 필요가 있다. 이를 확인해주는 곳이 Certificate Authority, CA라고 하는 곳이다. 브라우저(크롬, IE, Firefox 등...)에는 이러한 CA들의 목록이 있다. 

 

클라이언트는 랜덤한 데이터를 생성해서 서버에 보내고, 서버는 이를 받고 역시 랜덤한 데이터를 생성하여 클라이언트 측에 보낸다. 그러면서 서버의 인증서도 보낸다. 이를 handshake 라 한다. 그리고 클라이언트는 이 인증서가 제대로 된 것인지 CA를 통해 검증한다. 이 과정을 구체적으로 서술하자면, 이러한 인증서들은 CA의 private key를 통해 암호화된 것이기 때문에, CA의 public key를 통해서만 복호화할 수 있다. 즉, CA가 발급해준 인증서가 아니면 복호화되지 않는다. 이를 통해 클라이언트는 서버가 공인된 서버인지 아닌지 판단 가능하다. 그리고 이러한 인증서에는 서버의 공개키가 들어있다. 

 

하지만 이러한 public key private key를 통한 암호화 복호화는 컴퓨터에 상당한 연산을 필요로 한다. 그러므로 대칭키를 활용한 방법이 필요하다. 그 방법은, 서버와 클라이언트가 handshake를 할때에 생성된 두 무작위 데이터를 일련의 과정을 통해 임시 키를 생성하고, 서버의 public key를 통해 암호화를 하고 이를 서버에 전송한다. 서버와 클라이언트는 동일한 일련의 과정을 통하여 이를 서로 모두 가지고 있는 대칭키를 생성할 수 있다. 이제 앞으로 데이터를 전송할 때 이를 활용하면 된다.