[AWS] SSL/TLS란?
A. Question
SSL과 TLS는 무엇일까?
B. Answer
SSL(보안 소켓 계층, Secure Sockets Layer) 및 TLS(전송 계층 보안, Transport Layer Security)는 인터넷 상에서 데이터의 암호화 및 보안 전송을 위해 사용되는 프로토콜이다. 이 두 기술은 웹 브라우저와 서버 간의 데이터 전송을 보호하고, 데이터의 기밀성(외부에 노출되지 않음)과 무결성(전송 중 변경되지 않음)을 보장한다.
HTTPS(HyperText Transfer Protocol Secure)은 HTTP에 SSL/TLS를 결합하여 데이터 전송을 암호화하고 보안을 강화한 버전이다. HTTPS를 사용하면 브라우저와 서버 간의 데이터는 암호화되어 전송되며, 제3자가 데이터를 가로채도 내용을 이해할 수 없다.
1. SSL과 TLS의 차이
- SSL은 원래 인터넷 통신을 암호화하기 위해 개발된 초기 보안 프로토콜이다. 그러나 보안상의 문제로 더 이상 사용되지 않고 있으며, TLS로 대체되었다.
- TLS는 SSL의 후속 버전으로, 더 강력한 암호화 알고리즘과 보안 기능을 제공하여 SSL의 취약점을 보완한 프로토콜이다. 현재 사용되는 SSL/TLS라고 부르는 기술 대부분은 TLS를 의미한다.
2. 데이터 암호화
- SSL/TLS는 클라이언트(웹 브라우저)와 서버 간의 데이터 전송을 암호화하여 중간자 공격(Man-int-the-Middle Attack)과 같은 공격으로부터 데이터를 보호한다.
- 비대칭 암호화는 초기 핸드셰이크 과정에서 사용되며, 안전하게 세션 키를 교환하는 데 사용된다. 이후 데이터 전송은 성능을 위해 대칭 암호화로 처리된다.
- 데이터를 가로채더라도 암호화되어 있으므로, 공격자가 해독하지 못해 데이터의 기밀성이 유지된다. 예를 들어, 로그인 정보나 결제 세부정보 등 민감한 데이터가 보호된다.
2.1. 대칭 암호화
- 정의: 대칭 암호화는 하나의 동일한 키를 사용하여 데이터를 암호화하고 복호화하는 방식이다. 송신자와 수신자는 동일한 키를 공유해야 하며, 이 키는 비밀로 유지된다.
- 장점: 대칭 암호화는 속도가 빠르고 효율적이다. 따라서 많은 양의 데이터를 처리하는 데 적합하다.
- 단점: 안전한 키 공유가 어렵다. 송신자와 수신자는 키를 안전하게 교환해야 하며, 키가 유출되면 데이터가 쉽게 해독될 수 있다.
- 사용 예시: TLS 프로토콜에서 클라이언트와 서버가 세션 키 교환 후 대칭 암호화를 사용해 데이터를 암호화하여 성능을 최적화한다.
2.2. 비대칭 암호화
- 정의: 비대칭 암호화는 공개 키와 개인 키라는 두 개의 서로 다른 키를 사용하는 방식이다. 공개 키는 누구나 볼 수 있으며 데이터를 암호화하는 데 사용된다. 개인 키는 소유자만 알고 있으며 데이터를 복호화하는 데 사용된다.
- 장점: 키를 공유할 때 보안성이 높다. 공개 키는 누구에게나 공유할 수 있지만, 데이터를 해독하려면 개인 키가 필요하다.
- 단점: 비대칭 암호화는 계산 속도가 느리다. 때문에 대량의 데이터를 처리하기에는 효율적이지 않다.
- 사용 예시: SSL/TLS 핸드셰이크 과정에서 클라이언트와 서버 간의 세션 키 교환 시 사용된다. 클라이언트는 서버의 공개 키를 사용해 세션 키를 암호화하고, 서버는 자신의 개인 키로 이를 복호화하여 안전하게 세션 키를 교환한다.
2.3. SSL/TLS에서의 암호화 사용 방식
(1) 초기 핸드셰이크
- 비대칭 암호화가 사용된다. 클라이언트는 서버의 공개 키를 사용해 세션 키를 암호화하여 서버로 전송한다. 서버는 자신의 개인 키로 세션 키를 복호화한다.
- 이 과정을 통해 클라이언트와 서버는 안전하게 대칭 키(세션 키)를 공유할 수 있게 된다.
(2) 데이터 전송
- 이후의 데이터 전송은 대칭 암호화로 처리된다. 이는 데이터 전송의 속도와 효율성을 높이기 위해 사용된다.
- 세션 키를 사용해 데이터를 암호화하므로, 가로채더라도 공격자가 세션 키를 모른다면 데이터를 해독할 수 없다.
3. 데이터 무결성
- SSL/TLS는 데이터가 전송 중 변경되거나 손상되지 않았음을 보장하기 위해 메시지 인증 코드(MAC) 또는 해시 함수를 사용한다.
- 무결성 검증은 전송된 데이터가 도착 시점에서도 원래 전송된 상태와 동일한지 확인하는 과정이다. 이를 통해 데이터가 중간에 변조되거나 손상된 경우 즉시 탐지할 수 있다.
- TLS 1.2는 SHA-256과 같은 강력한 해시 알고리즘을 사용해 무결성을 보장하며, TLS 1.3에서는 이를 더욱 개선하여 데이터의 보안성을 강화했다.
3.1. 해시 알고리즘을 이용한 무결성 검증 과정
(1) 해시 함수 생성
- 데이터가 전송되기 전에 송신 측(예: 서버)은 데이터를 입력으로 받아 해시 함수(예: SHA-256)을 적용한다. 해시 함수는 입력 데이터를 고정된 길이의 해시 값(또는 해시 코드)으로 변환한다. 이 해시 값은 데이터의 고유한 서명 역할을 한다.
(2) MAC 생성
- 송신 측은 해시 값과 데이터를 함께 전송하거나,
MAC(Message Authentication Code)를 만들어 전송한다. - MAC 생성: 송신 측(예: 서버)은 전송할 데이터를 비밀 키와 결합한 후 해시 함수(예: SHA-256)를 사용해 MAC을 생성한다. MAC은 데이터의 고유한 서명처럼 작동해 데이터의 무결성을 보장한다.
(3) MAC과 데이터 전송
- 생성된 MAC과 원본 데이터는 함께 전송된다. 이때 비밀 키는 안전하게 송신자와 수신자만 알고 있으며, 네트워크 상으로는 전송되지 않는다. MAC은 데이터가 중간에서 변조되지 않았는지를 확인하는 데 사용된다.
(4) 수신 측에서의 검증
- 수신 측은 전송받은 데이터를 같은 비밀 키와 해시 함수로 다시 MAC을 생성한다. 송신 측에서 보낸 MAC과 수신 측이 생성한 MAC을 비교하여 데이터가 변조되지 않았는지 확인한다.
3.2. 예시: SHA-256 해시 알고리즘
- SHA-256은 TLS 1.2에서 널리 사용되는 강력한 해시 알고리즘이다. 이 알고리즘은 입력된 데이터의 내용을 기반으로 256비트 길이의 고정된 해시 값을 생성한다.
- 입력 데이터의 아주 작은 변화(예: 한 글자 수정)만 있어도 해시 값이 완전히 달라진다. 이를 통해 데이터가 조금이라도 변경되었는지를 쉽게 탐지할 수 있다.
3.3. 왜 해시 알고리즘과 MAC을 사용하는가
- 해시 알고리즘만 사용할 경우, 해시 값은 원본 데이터를 기반으로 생성되지만, 그 자체로는 비밀 요소가 없기 때문에 공격자에 의해 쉽게 변조될 수 있다. 공격자가 데이터와 해시 값을 동시에 변경하면, 수신 측은 이를 감지하지 못하고 데이터가 무결하다고 잘못 판단할 수 있다.
- 이를 방지하기 위해 MAC(Message Authentication Code)은 비밀 키를 사용하여 보호된 해시 값을 생성한다. MAC은 데이터와 비밀 키를 결합해 생성되므로, 공격자가 데이터와 해시 값을 변조하더라도 동일한 비밀 키가 없으면 올바른 MAC을 생성할 수 없다.
4. 인증
- SSL/TLS 프로토콜의 중요한 기능 중 하나는 서버와 클라이언트 간의 인증이다. 이를 통해 양쪽 당사자는 서로의 신뢰성을 확인할 수 있으며, 안전한 데이터 전송을 보장받을 수 있다. 인증 과정은 주로 디지털 인증서를 사용하여 수행된다.
4.1. 디지털 인증서란
- 디지털 인증서는 서버나 클라이언트의 신원을 확인하기 위해 사용되는 전자 문서이다. 이 인증서는 공개 키와 함께 해당 키의 소유자의 신원을 증명하는 정보를 포함한다.
인증 기관(CA, Certificate Authority)는 신뢰할 수 있는 제3자로, 디지털 인증서를 발급하고 이를 통해 인증된 서버나 클라이언트가 신뢰할 수 있음을 보장한다.
4.2. 디지털 인증서 발급 과정
(1) 인증서 요청
- 서버 또는 클라이언트는
CSR(Certificate Signing Request)라는 인증서 서명 요청을 생성하여 인증 기관(CA)에 제출한다. 이 요청에는 공개 키와 소유자의 신원 정보가 포함된다. - CSR에 공개 키를 포함하는 이유는 CA가 발급할 인증서에 이 공개 키를 포함시켜 인증서 소유자의 신원을 보증하기 위해서이다.
(2) 신원 검증
- CA는 CSR에 포함된 정보를 바탕으로 신청자의 신원을 검증한다. 이 검증 단계는 인증서의 유형에 따라 다르다.(예: 도메인 검증
DV, 기관 검증OV, 확장 검증EV) - DV 인증서는 도메인 소유권만 확인하며, OV와 EV 인증서는 조직의 실체와 법적 존재 여부까지 확인한다.
(3) 인증서 발급
- CA는 검증이 완료되면 신청자의 공개 키에 디지털 서명을 추가하여 디지털 인증서를 발급한다.
- 발급된 인증서는 서버나 클라이언트가 자신을 증명하는 데 사용된다.
4.2. SSL/TLS 인증 과정
(1) 서버의 디지털 인증서 전송
- SSL/TLS 핸드셰이크 과정에서 서버는 클라이언트에게 자신의 디지털 인증서를 전송한다.
- 이 인증서는 서버의 공개 키와 CA의 디지털 서명을 포함하고 있다.
(2) 클라이언트의 인증서 검증
- 클라이언트는 서버로부터 받은 인증서를 검증한다. 이 과정에서 클라이언트는 다음 단계를 수행한다.
- 인증서의 발급자를 확인하고, 클라이언트가 신뢰할 수 있는 루트 인증서와 일치하는지 확인한다.
- CA의 디지털 서명을 확인하여 인증서가 변조되지 않았음을 보장한다.
- 인증서의 유효 기간을 확인하여 만료되지 않았는지 검토한다.
- 클라이언트가 인증서를 신뢰할 수 있음을 확인하면, 서버와의 통신이 안전하다고 판단한다.
(3) 인증 성공 시
- 클라이언트는 서버가 신뢰할 수 있는 조직이나 도메인임을 확인하게 되며, 이후 데이터 교환에 필요한 세션 키 교환을 비대칭 암호화 방식으로 시작한다.
(4) 클라이언트 인증(옵션)
- 일반적으로 SSL/TLS에는 서버 인증만 필요하지만, 양방향 인증이 필요한 경우 클라이언트도 자신의 디지털 인증서를 서버에 제공할 수 있다.
- 이는 은행이나 금융 서비스처럼 높은 보안 수준이 필요한 애플리케이션에서 사용된다.
- 서버는 클라이언트가 전송한 인증서를 검증하여 클라이언트의 신원을 확인하고, 인증에 성공하면 양방향 보안 통신이 가능하다.
4.3. 인증의 중요성
- 보안 강화: 클라이언트는 서버가 진짜로 자신이 접속하려는 사이트임을 확신할 수 있다. 이는 중간자 공격이나 피싱 사이트와 같은 위협을 방지한다.
- 데이터 기밀성: 인증 과정이 성공적으로 완료되면, 양측은 데이터를 안전하게 암호화하여 교환할 수 있는 세션 키를 설정할 수 있다.
- 무결성 보장: 인증서를 통한 검증은 데이터가 중간에서 변조되지 않았다는 것을 보장한다.
4.4. 디지털 인증서의 유형
(1) 도메인 검증(DV)
- 도메인 소유권만 확인하는 기본 인증서로, 발급이 빠르고 비용이 저렴하다.
- 일반적인 웹사이트에서 사용되며, 기본적인 암호화 및 신원 확인을 제공한다.
(2) 기관 검증(OV)
- 도메인 소유권 외에 조직의 신원도 확인하는 인증서이다.
- 사용자에게 도메인 소유자가 인증된 회사나 기관임을 알려준다.
(3) 확장 검증(EV)
- 가장 높은 신뢰 수준을 제공하는 인증서로, 엄격한 검증 절차를 거친다.
- 브라우저의 주소창에 회사 이름과 함께 녹색 자물쇠 아이콘이 표시되어 사용자가 신뢰할 수 있는 사이트임을 즉각 확인할 수 있다.
5. 동작 방식
핸드셰이크 과정에서 클라이언트와 서버는 데이터를 안전하게 암호화하기 위해 세션 키를 교환하며 서로를 인증한다.
(1) 초기 요청
- 클라이언트는 서버에 연결 요청을 하며, 지원하는 SSL/TLS 버전과 암호화 알고리즘 목록을 보낸다.
(2) 서버 응답
- 서버는 클라이언트가 보낸 정보를 바탕으로 암호화 알고리즘과 프로토콜 버전을 선택하고, 자신의 디지털 인증서를 클라이언트에 보낸다.
(3) 인증서 검증
- 클라이언트는 서버의 인증서를 확인하고 신뢰할 수 있음을 검증한 후, 세션 키를 암호화해 서버로 보낸다.
(4) 암호화된 통신 시작
- 서버는 세션 키를 사용해 클라이언트와의 암호화된 데이터 전송을 시작한다.
6. SSL/TLS의 사용 사례
- 웹사이트 보안: 웹사이트가 HTTPS로 시작하는 경우 SSL/TLS 프로토콜을 사용하여 보안 연결을 제공하고 있음을 나타낸다.
- 전자상거래 및 금융 거래: 온라인 결제 시스템에서 사용자 데이터와 결제 정보를 안전하게 전송하기 위해 SSL/TLS가 사용된다.
- API 보안: 클라이언트와 서버 간의 안전한 데이터 전송을 위해 API 통신에서도 SSL/TLS가 사용된다.
댓글남기기