[네트워크] - SSL

SSL(Secure Sockets Layer)

---

최근에 사람들이 주로 사용하는 웹 사이트들은 모두 HTTPS 형식의 통신을 하는 것을 알 수 있다.

이러한 HTTPS 통신은 기존의 HTTP 통신에 SSL 프로토콜을 결합한 통신 프로토콜인데 그렇다면 왜 굳이 SSL 프로토콜을 결합해서 통신을 하는 것일까?

기존의 HTTP 통신에서는 한 가지 중요한 문제가 있는데 그것은 바로 HTTP 통신으로 데이터를 전달하게 되면 아무런 보안 장치 없이 있는 그대로 데이터를 보낸다는 것이었다.

중요한 정보가 담긴 데이터를 보낸다고 했을 때 중간에 공격자가 해당 데이터를 확인하면 어떤 내용인지 바로 확인할 수 있어 굉장히 큰 보안 문제를 야기할 수 있다.

이러한 문제를 해결하기 위해서는 데이터를 전달할 때 다른 사람에게 노출되어도 내용을 확인할 수 없도록 보안 기술을 적용해야 하는데 이때 등장한 기술이 바로 SSL 기술이다.

SSL은 데이터를 전송할 때 암호화를 기반으로 하는 인터넷 보안 프로토콜로 우리가 흔히 사용하는 HTTPS의 S가 해당 SSL을 의미하는 것이다.

SSL 프로토콜을 사용하면 사용자와 웹 서버 사이를 이동하는 모든 데이터를 암호화할 수 있는데 그러기 위해서는 SSL 인증서라는 것이 꼭 필요하다.

해당 SSL 인증서에 포함된 가장 중요한 정보 중 하나가 웹 사이트의 공개 키인데 CA(인증기관)라는 곳에서 해당 SSL 인증서 발행을 담당하게 된다.

그렇다면 SSL 프로토콜은 어떻게 데이터를 암호화를 하는지 생각해 보면 이전에 배웠던 암호화 알고리즘이 적용되는 것을 알 수 있다.

[알고리즘] - 암호화

 

마지막으로 SSL 프로토콜은 어떻게 동작하는지 보면 간단하게 아래와 같이 동작하게 된다.

• SSL 동작 과정

1. 클라이언트가 서버에 접속을 시도한다.
2. 서버는 클라이언트에게 SSL 인증서를 보낸다.
3. 클라이언트는 인증서를 검증하고, 서버의 공개 키를 사용하여 세션 키를 암호화한다.
4. 서버는 자신의 비밀 키를 사용하여 세션 키를 복호화한다.
5. 이후의 통신은 세션 키를 사용하여 암호화한다.

위와 같은 동작 과정이 어떻게 해서 나온 것이고, 왜 그렇게 해야하는지 하나씩 살펴보며 이해해 보자.

 

SSL 동작 과정 살펴보기

---

• 비대칭 키를 활용한 암호화 통신

본격적인 SSL 프로토콜의 동작을 알아보기 전에 웹 사이트와 통신할 때 어떻게 데이터를 암호화하는지 알아보자.

기본적으로 네트워크 통신에 사용되는 암호화 방식은 비대칭 키 암호화를 사용한다.

대칭 키 암호화를 하게 되면 키를 교환하는 과정에서 문제가 발생할 수 있기 때문에 비대칭 키를 사용하게 된다.

먼저 비대칭 키 암호화를 하기 위해서는 공개 키와 비밀 키가 필요하기 때문에 사용자의 PC와 웹 서버가 각각의 키 쌍을 생성한다.

키 쌍을 생성했다면 사용자 PC와 웹 서버 간의 공개 키를 서로 교환을 한다.

 

공개 키 교환이 완료되면 사용자 PC에서는 웹 서버의 공개 키로 데이터를 암호화해 전달해 주고, 해당 웹 서버는 받은 암호문을 자신의 비밀 키로 복호화하여 데이터를 확인할 수 있다.

이렇게 비대칭 키를 사용하여 암호화 통신을 하게 되면 기존의 문제가 되었던 보안 부분을 개선할 수 있다.

하지만 비대칭 키를 사용한 암호화 통신에서는 문제가 있는데 바로 효율이 떨어진다는 점이다.

이전에 암호화에 대해서 공부를 했을 때 대칭 키와 비대칭 키를 비교했던 것을 생각해 보면 보안적인 부분은 비대칭 키가 더 우수할 수 있지만, 효율 부분에서는 대칭 키가 훨씬 우수하다.

간단하게 생각해 봐도 키를 하나 사용하는 것을 두 개로 사용하는 것이기 때문에 암호화 및 복호화하는 과정이 더 오래 걸리게 되고 비대칭 키를 사용하는 암호화 알고리즘은 대칭 키보다 훨씬 더 많은 비트 수를 사용하게 된다.

이렇게 많은 비용이 들고 효율이 떨어지는 비대칭 키를 매번 통신할 때마다 생성해줘야 한다면 전체적인 서비스의 성능이 떨어질 수밖에 없다.

이러한 비용 문제와 효율 문제를 해결하기 위해서는 비대칭 키 보다 좋은 성능을 보여주는 대칭 키를 혼합해서 사용해야 한다.

 

• 대칭 키와 혼합해서 사용하는 암호화 통신

대칭 키와 비대칭 키를 혼합해서 사용하는 암호화 통신을 예제로 알아보자.

먼저 사용자 PC에서는 대칭 키를 생성하고 웹 서버에서는 공개 키와 비밀 키 쌍을 생성한다.

사용자 PC에서는 웹 서버로부터 공개 키를 전달받는다.

 

사용자 PC에서는 전달받은 웹 서버의 공개 키로 자신의 대칭 키를 암호화해 웹 서버로 전달해 준다.

이때 중요한 것은 데이터를 공개 키로 암호화를 하는 것이 아닌 사용자 PC의 대칭 키를 암호화하는 것이다.

대칭 키에서 항상 문제가 되었던 부분은 키를 교환하는 과정이었다.

아무런 보안 조치 없이 대칭 키를 교환하게 되면 공격자가 해당 키를 탈취할 수 있는 문제가 존재하기 때문에 이러한 대칭 키를 공개 키로 암호화해서 전달하는 것이다.

웹 서버는 암호화된 대칭 키를 받으면 자신의 비밀 키로 복호화하여 사용자 PC의 대칭 키를 얻을 수 있게 된다.

 

대칭 키 교환이 완료된 이후 사용자 PC에서는 데이터를 대칭 키로 암호화하여 웹 서버로 전달하게 되고, 웹 서버는 이전에 복호화해놓은 대칭 키로 암호문을 복호화해 데이터를 확인할 수 있게 된다.

여기서 중요한 용어가 나오는데 이러한 대칭 키 교환을 세션 키라고도 부른다.

즉, 두 통신 단말기 간의 네트워크에서 암호화 통신을 위한 세션 키를 만들어 놓고 해당 세션 키를 통해서 데이터를 암호화 및 복호화를 하게 된다.

네트워크 통신이 종료되고 연결이 끊긴 후 다시 재연결을 할 경우 이러한 세션 키는 다시 생성된다.

여기 까지만 보면 완전한 암호화 통신이 이루어질 것 같지만 한 가지 의문점이 들 수 있는데 사용자 PC에서 받은 웹 서버의 공개 키가 진짜 사용자가 필요한 공개 키인지 어떻게 신뢰할 수 있을지 의문이 든다.

예를 들어 위의 그림과 같이 사용자 PC와 웹 서버 간의 통신 중에서 중간에 공격자가 끼어들었다고 가정해 보자.

 

원래는 웹 서버에서 공개 키를 사용자 PC에게 보내줘야 하지만 중간에 공격자가 해당 공개 키를 가로채고 공격자의 공개 키를 대신 전달할 수 있다.

 

사용자 PC는 공격자가 보낸 공개 키라고 생각하지 못하고 해당 공개 키로 자신의 대칭 키를 암호화해 다시 웹 서버로 전달한다.

이때 공격자는 다시 암호화된 대칭 키를 가로채서 자신의 비밀 키로 복호화를 하면 사용자 PC에서 생성한 대칭 키를 확인할 수 있게 된다.

이렇듯 중간에서 공격자가 사용자 PC의 대칭 키를 복호화할 수 있기 때문에 사용자가 받는 공개 키를 신뢰할 수 있는 체계가 있어야 한다.

 

• 인증기관을 통한 암호화 통신

그러면 어떻게 공개 키를 신뢰할 수 있을까?

신뢰할 수 있는 방법으로는 제3의 기관을 두면 된다. 이러한 제 3의 기관을 통해 사용자가 받는 공개 키가 정상적인 공개 키라는 것을 신뢰할 수 있게 된다.

여기서 제 3의 기관은 CA(Certificate Authority, 인증기관), RA(Registration Authority, 등록기관)라고 한다.

인증 기관을 두게 된다면 웹 서버에서는 키 쌍을 생성하지 않고 인증 기관을 통해서 키 쌍을 전달받는다.

 

서비스를 운영하는 회사가 RA에게 키 쌍을 요청한다. 그러면 RA에서 공개 키와 비밀 키 쌍을 생성하여 전달해 주게 된다.

웹 서버는 받은 키 쌍을 저장하게 되는데 여기서 RA가 생성해 준 공개 키가 중요하다.

해당 공개 키에는 여러 가지 정보가 담기는데 아래와 같은 정보가 담긴다.

이러한 정보들이 담긴 공개 키를 바로 인증서라고 부른다.

 

사용자 PC는 웹 서버로부터 인증서 즉, RA에서 발급해 준 공개 키를 전달받게 된다.

사용자 PC는 전달받은 인증서를 검증해야 하는데 이때 검증을 CA에게 맡긴다.

생각해 보면 사용자가 받은 인증서는 RA에서 생성했는데 왜 검증은 CA에서 해야 되는 것일까?

이전에 RA에서 만들어주는 인증서에는 해시 값이 포함되어 있는데 해당 해시 값은 인증서의 모든 정보를 암호화한 것이다. 또한 지문이라는 정보는 해시 값을 다시 암호화한 것으로 해당 지문을 복호화하면 인증서의 정보들을 알 수 있다.

 

이때 해시 값을 RA가 암호화하는 것이 아닌 CA가 자신의 비밀 키를 통해서 해시 값을 암호화하여 지문을 생성하고, 나중에 복호화가 필요하면 CA의 공개 키로 복호화를 진행한다.

이렇게 CA를 통한 인증서 검증을 하게 되면 중간에 공격자가 인증서를 바꿔도 보안 문제가 발생하지 않게 된다.

왜냐하면 공격자가 인증서를 바꾸게 되면 인증서에 들어있는 해시 값과 지문 정보가 달라지기 때문이다.

 

웹 서버에서 전달받은 인증서를 어떻게 검증하는지 살펴봤는데 그러면 CA의 공개 키는 어디에 있을까?

CA가 가지고 있는 공개 키도 인증서 형식을 갖추게 된다. 그렇다면 이러한 CA의 인증서도 전달받아야 하는데 따로 네트워크 통신 없이도 사용자 PC는 인증서를 검증할 수 있게 된다.

그게 가능한 이유는 사용자 PC에 이미 CA의 인증서가 저장되어 있기 때문이다.

certmgr.msc(컴퓨터 인증서 관리)를 통해서 확인할 수 있는데 실제로 찾아보면 인증서에 관한 여러 정보들을 확인할 수 있다.

이러한 CA 인증서들은 MS와 같은 회사에서 다른 CA 업체와 제휴하여 미리 인증서들을 저장해 놓은 것으로 소프트웨어 업데이트할 때 CA 인증서들도 같이 업데이트를 하게 된다.

 

참고 자료

널널한 개발자 - SSL 관련 영상

https://www.cloudflare.com/ko-kr/learning/ssl/what-is-a-session-key/

https://www.cloudflare.com/ko-kr/learning/ssl/what-is-ssl/