SSL / TLS

SSL / TLS 란?

• SSL / TLS는 애플리케이션을 암호화하는 프로토콜이다.
• HTTPS는 HyperText Transfer Protocol Secure의 약자로 HTTP를 SSL로 암호화한 것.

SSL에서 이용하는 암호화 방식

공통키 암호화 방식

공통키 암호화 방식은 암호화키와 복호화키로 동일한 키(공통키)를 사용하는 암호화 방식. 대칭키 암호화 방식이라고도 한다.
공통키 암호화 방식은 스트림 암호와 블록 암호로 나뉜다.

스트림 암호

• 1비트 단위 또는 1바이트 단위로 암호화 처리하는 암호화 방식.
• 블록 암호에 비해 빠르게 처리할 수 있지만, 대표적인 스트림 암호인 RC4에 취약성이 발견되어 지금은 사용하지 않는 경향이 있다.

블록암호

• 데이터를 일정 비트 수 단위(블록)로 구분해 하나하나 암호화 처리를 적용한다.
• 높은 확률로 AES를 사용한다.

장점

• 처리속도와 처리 부하.
• 구조가 단순하기 때문에 암 · 복호화가 빠르고 처리 부하가 크지 않다.

단점

• 키 전송 문제
  • 암 · 복호화 키가 같기 때문에 키가 유출되면 안 된다.
  • 키 공유를 신경 써야 한다.

공개키 암호화 방식

• 암호화키와 복호화키로 다른 키를 사용한다. 비대칭키 암호화 방식이라 부르기도 한다.
• RSA, 디피 헬만, 타원곡선 디피 헬만 등이 있다.

공개키: 누구에게나 공개할 수 있는 키.
비밀키: 모두에게 비밀로 해야 하는 키.

(공개키 + 비밀키) = 키페어

가장 많이 쓰이는 방식

1. 웹 서버는 키페어를 만든다.
2. 웹 서버는 공개키를 배포하고 비밀키만 보관한다.
3. 웹 브라우저는 공개키를 암호화키로 사용해서 데이터를 암호화한 뒤 전송
4. 웹 서버는 비밀키를 복호화키로 사용해서 데이터를 복호화한다.

장점

• 키 전송을 신경 쓰지 않아도 된다.

단점

암호화 처리와 복호화 처리에 많은 비용이 소요된다.

하이브리드 암호화 방식

공통키 방식과 공개키 방식의 장단점은 완벽히 반대이다. SSL은 두 방식을 적절히 조합해 처리 효율을 높인다.

암호화 방식	공통키 암호화 방식	공개키 암호화 방식
암호화 종류	3DES, AES, Camellia	RSA, DH/DHE, ECDHE
키 관리	통신 상대별로 관리	공개키롸 비밀키로 관리
처리 속도	빠름	느림
처리부하	가벼움	무거움
키 전송 문제	O	X

1. 웹 서버는 공개키와 비밀키를 만든다.
2. 웹 서버는 공개키를 모두에게 공개하고 비밀키만 보관.
3. 웹 브라우저는 공통키의 재료를 공개키로 암호화하여 서버에 전송
4. 웹 서버는 암호화된 공통키의 재료를 비밀키로 복호화한다.
5. 웹 서버와 웹 브라우저는 공통키의 재료로부터 공개키를 생성한다.
6. 웹 브라우저는 애플리케이션 데이터를 공통키로 암호화한다.
7. 웹 서버는 애플리케이션 데이터를 공통키로 복호화한다.

SSL에서 사용하는 해시함수

• 해시화는 애플리케이션 데이터를 잘게 쪼개 같은 크기의 데이터로 모으는 기술
• 메시지 다이제스트 || 핑거프린트라고 부른다.

해시값을 비교하는 것이 효율적

• 데이터의 크기가 커지면 데이터를 해시화해서 비교하는 것이 원본을 비교하는 것보다 효과적이다.
• 데이터가 다르면 해시값이 다르고, 데이터가 같으면 해시값이 같다.
• 해시값에서 원 데이터를 복원할 수 없다.
• 같은 해시함수에서는 데이터 크기와 상관없이 같은 크기의 해시값이 나온다.

애플리케이션 데이터 검증

해시화의 가장 전형적인 사용방법이다. 송신자는 데이터와 해시값을 전송하고, 수신자는 데이터로부터 해시값을 계산하고 비교하여 변조를 판단한다.

SSL에서는 간단한 단방향 해시 함수가 아닌, 메시지 인증 코드(MAC, Message Authentication Code)라는 기술을 사용한다.
메시지 인증 코드는 애플리케이션 데이터와 MAC키(공통키)를 섞어 MAC값(해시값)을 계산하는 기술이다. 단방향 해시 함수에 공통기의 요소가 추가되므로 변조 감지뿐만 아니라 상대를 인증할 수 있다.

디지털 인증서 검증

SSL에서는 디지털 인증서의 검증에도 해시화를 사용한다. SSL에서는 디지털 인증서를 사용해 자신이 자신이고, 상대가 상대임을 증명한다. 제3자 '인증기관(CA)'을 통해 디지털 서명이라는 형태로 승인받는다. 이 서명에 해시화가 사용된다.

디지털 인증서는 서명 전 인증서, 디지털 서명 알고리즘, 디지털 서명으로 구성된다.

서명 전 인증서

서버나 서버 소유자의 정보. 서버의 URL을 나타내는 공통이름이나 인증서 유효기간, 공개키 등이 여기에 포함된다.

디지털 서명 알고리즘

디지털 서명에서 사용하는 해시 함수 이름이 포함된다.

디지털 서명

서명 전 인증서와 디지털 서명의 알고리즘으로 지정된 해시 함수로 해시화 한 뒤, 인증기관의 비밀키로 암호화한 것.

디지털 인증서를 받은 수신자는 디지털 서명을 인증기관의 공개키(CA 인증서)로 복호화해서 서명 전 인증서의 해시값과 비교, 검증한다.

TLS 접속에서 종료까지

서버 인증서 준비

HTTPS 서버로 공개하기 위해서는 서버 인증서를 준비, 인증기관으로의 신청 등을 사전에 준비해야 한다.

1. HTTP 서버에서 비밀키 생성
2. 1에서 만든 비밀키를 기반으로 CSR(Certificate Signing Request)을 만들어 인증기관에 전송. CSR이란 서버인증서를 얻기 위해 인증 기관에 제출하는 신청서와 비슷하다. 서버관리자는 서명 전 인증서의 정보를 입력해 CSR을 만든다. CSR을 만들기 위해 필요한 정보는 고유이름이라 부른다. CSR은 서명 전 인증서의 정보를 암호화한 텍스트 파일이다.
3. 인증기관이 신청자의 신원을 조사한다. 조사는 다양한 여신(신용) 데이터를 조회하거나 제3자 기관의 데이터베이스에 기재된 전화번호로 전화하는 등 인증기관 안에서 정해진 여러 프로세스에 기반해 수행한다. 조사를 통과하면 CSR을 해시화, 인증기관의 비밀키로 암호화해서 디지털 서명으로 만든다. 그리고 인증기관은 서버인증서를 발생하고 요청자에게 송신한다.
4. 인증기관에서 받은 서버 인증서를 서버에 설치한다.

TLS 핸드셰이크를 통한 사전 준비

메시지를 암호화하기 전에 암호화하기 위한 정보나 통신 상대를 확인하는 사전 준비를 처리하는 SSL 핸드셰이크라는 단계를 갖는다.

TLS는 TCP의 3-way-handshake로 TCP 커넥션을 연 뒤, 핸드셰이크 레코드를 이용해 SSL 핸드셰이크하고, 여기에서 결정된 정보를 기반으로 메시지를 암호화한다. SSL 핸드셰이크는 대응방식 제시, 통신상대 증명, 공통키 재료 교환, 최종확인 4단계로 구성되어 있다.

참고

• 그림으로 공부하는 TCP/IP 구조