TLS(Transport Layer Security)는 온라인 네트워크에서 데이터를 안전하게 주고받기 위한 암호화 프로토콜이다.
우선 암호화 방식에 대해서 두 가지 알아보자면 다음과 같이 나뉜다.
- 대칭키 암호화(Symmetric Encryption)
- 암호화와 복호화에 같은 키를 사용
- 키를 수신기와 교환해야 하므로(같은 키니까) 해커가 키에 접근해 데이터를 해독할 위험이 있음
- 비대칭키 암호화(Asymmetric Encryption)
- public key로 암호화, private key로 복호화(즉, 다른키 사용)
- 공개키가 해킹당한다고 해도 개인키를 알지 못하면 복호화를 할 수 없어 안전
- RSA 알고리즘을 통해 데이터를 주고 받는데, 이는 복잡한 수학적 원리로 이루어져 있어 CPU 리소스를 크게 소모
그래서, TLS는 두 가지 방식을 보완하여 사용한다. 처음에 대칭키를 서로 공유하는 통신을 RSA 비대칭키 방식을 이용하고, 실제 통신을 할 때는 CPU 리소스 소모가 적은 대칭키 방식으로 데이터를 주고 받는다. 즉, 대칭키를 옮기기 위해 비대칭키 암호화를 사용한다.(서버에 공용과 개인키 쌍 생성)
과정을 간단히 정리하면 다음과 같다.
OpenSSL은 네트워크를 통한 데이터 통신에 쓰이는 프로토콜인 TLS/SSL의 오픈소스 구현판
- openssl 명령어를 이용해 개인키와 공용키 쌍 생성
- 사용자가 https를 이용해 웹서버에 처음 접근하면 서버는 자신의 공용키를 포함한 인증서를 사용자에게 전송. 해커가 모든 네트워크를 엿보고 있으니 해커도 공용키를 엿볼 수 있지만, 개인키는 서버에만 남아 있음.
- 그럼 사용자의 브라우저가 서버가 제공한 공용키를 이용해 대칭키를 암호화한다.(이 대칭키는 이후 통신에서 사용될 암호화 키)
- 그리고 사용자는 공용키로 암호화된 대칭키를 서버로 보낸다. 해커도 사본을 받을 수는 있지만, 서버의 개인키 없이는 해독할 수 없다.
- 서버는 개인 키로 메시지를 해독하고 대칭키를 회수한다. 해커에겐 암호를 해독할 개인키가 없고, 공개키만 갖고 있기 때문에 메시지에서 대칭키를 되찾을 수 없다.
- 이제 클라이언트와 서버는 대칭키로 데이터를 암호화해서 서로에게 보낼 수 있다. 상대방은 암호화된 데이터를 대칭키를 통해 해독할 수 있다.
(개인키와 공용키는 쌍을 이루며, 데이터를 해독하거나 디지털 서명을 확인하는 데 사용)
# RSA 알고리즘을 사용해 1024비트의 개인키 생성
$ openssl genrsa -out my-bank.key 1024
# 앞서 생성한 개인키(my-bank.key)를 사용해 공용키를 추출하고, 이를 mybank.pem으로 저장
$ openssl rsa -in my-bank.key -pubout > mybank.pem 하지만, 해커가 악의적으로 비슷한 서버를 만들 수도 있다. 따라서 서버에서 나온 키가 합법적인 키인지 확인이 필요한다. 그래서, 서버가 키를 보낼 때 키 대신 키를 가진 인증서를 보낸다.
인증서 자체는 누구나 만들 수 있으므로, 인증서를 생성했다면 직접 '서명' 해서 증명해야 한다. 브라우저는 서버에서 받은 인증서가 합법적인지 유효성을 확인하고 고정된 인증서라면 우리에게 경고(갱신 및 변경 등의 관리 이슈)를 준다.
웹 브라우저가 신뢰할 만한 합법적인 웹 서버 인증서는 CA(Certificate Authority)라는 인증서에 서명하고 유효성을 확인해주는 잘 알려진 기관에 의해 만들어진다.
먼저, 생성한 키와 우리의 웹사이트 도메인 이름을 이용해 CSR(Certificate Signing Request)파일을 생성한다(by openssl). CSR 파일은 인증서 서명 요청으로, CA로 보내져 서명을 받아야 한다. 인증서 관계자가 상세 사항을 확인하고 일단 확인되면 인증서에 서명해서 다시 보내준다.
만약, 해커가 같은 방법으로 인증서에 서명을 받으려 하면 인증서 유효성 검사 단계에서 실패할 것이다. 그가 호스팅 하는 웹사이트엔 유효한 인증서가 없어서 CSR이 거부당할 것이기 때문이다.
그렇다면 합법적인 CA가 서명했다는 것은 어떻게 알 수 있을까?
CA들은 개인키와 공용키 쌍을 갖고 있다. CA가 인증서에 서명할 때 개인키를 사용한다. 모든 CA의 공개키는 브라우저에 기본으로 제공되기 때문에 브라우저는 CA의 공개키를 이용해 CA가 직접 서명한 인증서임을 확인할 수 있다. (일반적인 개인키-공용키와 반대로 공용키가 암호 해독에 사용된다.
요약
메시지를 암호화하려면 공용키와 개인키로 비대칭 암호화를 해야 한다.
- 서버는 먼저 CA에 CSR을 보낸다. CA는 개인키로 CSR에 서명한다. 모든 사용자(브라우저)는 CA의 공용키를 갖고 있다.
- 서명된 인증서는 서버로 다시 보내진다. 서버는 서명된 인증서로 웹 응용 프로그램을 구성한다.
- 사용자가 웹 응용 프로그램에 접근할 때 마다 서버는 먼저 인증서(공개키)를 보낸다.
- 사용자, 정확히는 사용자의 브라우저가 인증서를 읽고 서버의 공개키를 유효성 검사하고 회수하기 위해 CA의 공용키를 사용한다(CA 검증).
- 그런 다음 대칭키를 생성해 모든 통신에 사용하려 한다. 대칭키는 서버의 공개키로 암호화되어 서버에 전송된다.
- 서버는 개인키로 메시지를 해독하고 대칭키를 회수한다.
- 대칭키는 앞으로 통신을 위해 사용된다.
