SSL/TLS
인터넷상에서 통신할 때 주고받는 데이터를 보호하기 위한 표준화된 암호화 프로토콜
- 전송 계층 상에서 클라이언트, 서버에 대한 인증 및 데이터 암호화 수행
- 클라이언트와 서버 양단간 응용 계층 및 TCP 전송 계층 사이에서, 안전한 보안 채널을 형성해 주는 역할을 하는 “보안용 프로토콜”
- 주요 응용
- 전송계층의 암호화 방식이기 때문에 HTTP(HTTPS), FTP(FTPS), TELNET, SMTP, SIP, POP, IMAP 등 응용 계층 프로토콜의 종류에 상관없이 사용 가능
- 주로, 웹 브라우저와 웹 서버 사이의 안전한 보안 채널을 제공하기 위해 많이 사용됨(HTTPS)
- 주요 지원 요소
- 암호화(Encryption): 개인정보 보호를 위해 제3자로부터 전송되는 데이터를 숨긴다.
- 높은 수준의 개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화한다. 따라서, 데이터를 가로채려는 자는 거의 해독할 수 없는 복잡한 문자만 보게 된다.
- 인증(Authentication): 정보를 교환하는 당사자가 요청된 당사자임을 보장한다.
- 두 통신 장치 사이에 핸드셰이크라는 인증 프로세스를 시작하여 두 장치의 ID를 확인한다.
- 무결성(Integrity): 데이터가 위조되거나 변조되지 않았는지 확인한다.
- 데이터 무결성을 제공하기 위해 데이터에 디지털 서명하여 데이터가 의도된 수신자에 도착하기 전에 조작되지 않았다는 것을 확인한다.
- 암호화(Encryption): 개인정보 보호를 위해 제3자로부터 전송되는 데이터를 숨긴다.
* HTTPS: HTTP 프로토콜 상위에서 TLS 암호화를 구현한 것. 따라서 HTTPS를 사용하는 웹 사이트는 SSL/TLS 암호화를 이용한다.
#SSL/TLS 는 왜 중요할까?
- 기존의 문제점
- 원래 웹 상의 데이터는 메시지를 가로채면 누구나 읽을 수 있는 일반 텍스트 형태로 전송
(예: 고객이 쇼핑 웹사이트를 방문하여 주문하고, 신용 카드 번호를 입력했다고 하면, 해당 신용 카드 번호가 숨겨지지 않은 채 인터넷을 이동하게 된다.)
- 원래 웹 상의 데이터는 메시지를 가로채면 누구나 읽을 수 있는 일반 텍스트 형태로 전송
SSL/TLS은 사용자와 웹 서버 사이를 이동하는 모든 데이터를 암호화하여, 누군가 데이터를 가로채더라도 무작위 문자만 볼 수 있게 합니다. 이제 고객의 신용 카드 번호는 안전해졌으며, 고객이 번호를 입력한 쇼핑 웹사이트만 이를 볼 수 있습니다.
SSL/TLS은 특정한 유형의 사이버 공격도 차단합니다. SSL은 웹 서버를 인증하는데, 공격자들이 사용자를 속여 데이터를 훔치기 위한 가짜 웹사이트를 만드는 일이 있기 때문에, 이러한 인증이 중요합니다. 또한, 공격자가 전송 중인 데이터를 조작하지 못하게 막기도 합니다.
SSL/TLS로 보호된 HTTPS는 급속하게 웹 사이트를 위한 표준 관행이 되고 있습니다. 예를 들어, Google Chrome 브라우저는 HTTPS가 아닌 사이트를 엄중 단속하고 인터넷 사용자는 HTTPS 자물쇠 아이콘이 없는 웹 사이트에 대해 더 조심하기 시작합니다.
#SSL 과 TLS 의 차이점
SSL (Secure Sockets Layer)
- Netscape가 개발한 TLS 이전의 암호화 프로토콜
TLS (Transport Layer Security)
- SSL에서 발전한 것.
- 1999년 IETF(Internet Engineering Task Force)가 SSL에 대한 업데이트를 제안하면서 IETF가 업데이트를 개발하고 Netscape는 더 이상 참여하지 않음.
- 소유권 변경을 나타내기 위해 프로토콜 이름이 TSL로 변경됨.
💡 SSL 과 TLS는 본질적으로 같으며 버전이 다른 정도라고 보면 된다.
- TLS를 아직 SSL이라 부르기도 하고, SSL의 인지도가 높기 때문에 ‘SSL/TLS 암호화’라 부르는 경우도 있는 것
[참고] 그렇다면 SSL은 아직 사용되고 있을까?
- SSL은 1996년 SSL 3.0 이후 업데이트되지 않았으며, 앞으로 사라지게 될 것으로 여겨지고 있다. SSL 프로토콜에는 알려진 취약성이 여러 가지 있으며 보안 전문가들은 SSL의 사용을 중단하라고 권장한다. 실제로, 최신 웹 브라우저는 대부분 이제 SSL을 지원하지 않는다.
(SSL이 갖고 있는 보안 취약성을 업데이트한 것이 TLS이고, 소유권 이전 이후 Netscape는 SSL에 대한 업데이트를 진행하지 않았기 때문에 당연한 결과로 보인다)
- TLS는 현재 온라인으로 실행되고 있는 최신 암호화 프로토콜인데, 아직 이를 "SSL 암호화"라고 부르는 사람도 있다. 실제로, 현재 "SSL"을 제공하는 업체는 사실상 TLS 보호를 제공하는 것이며, 이는 거의 20년 동안 업계 표준으로 자리 잡고 있다. 하지만 아직도 많은 고객이 "SSL 보호"를 찾고 있기 때문에, 많은 제품 페이지에 SSL/TLS 용어가 나타나고 있는 것이다.
#SSL 인증이란?
SSL은 SSL 인증서(공식적으로 "TLS 인증서")가 있는 웹사이트만 실행할 수 있다. SSL 인증서는 사람의 신원을 확인하는 신분증이나 배지와 같다. SSL 인증서는 웹사이트나 애플리케이션 서버가 웹에 저장하고 표시한다.
SSL 인증서는 공개 키와 개인 키라는 키쌍을 갖고, 인증서/웹사이트 소유자의 ID와 같은 "주체(subject)"를 포함한다. 이 공개 키 덕분에 암호화가 가능하다. 사용자의 장치는 공개 키를 보고 이를 이용하여 웹 서버와 안전한 암호화 키를 수립한다. 한편, 웹 서버에도 기밀로 유지하는 개인 키가 있다. 개인 키는 공개 키로 암호화된 데이터를 해독하는 역할을 한다.
SSL 인증서 발행은 CA(인증 기관)가 담당한다. SSL 인증서의 가장 중요한 부분은 신뢰할 수 있는 인증 기관이 디지털 방식으로 서명하는 것이다. 인증서는 누구나 만들 수 있지만 브라우저는 공인 인증 기관 목록에 포함된 조직에서 발급한 인증서만을 신뢰한다. 브라우저는 사전 설치된 공인 인증 기관 목록(Trusted Root CA store로 알려짐)이 포함되어 제공된다. Trusted Root CA store에 추가되어 인증 기관이 되려면 브라우저에서 지정한 보안 및 인증 표준을 준수하고 그에 대한 감사를 받아야 한다. 인증 기관이 조직과 그 도메인/웹사이트 발급한 SSL 인증서는 믿을 수 있는 제3자가 해당 조직의 신원을 인증했다는 것을 확인해준다. 브라우저가 인증 기관을 신뢰하기 때문에 이제 해당 조직의 신원도 신뢰하게 된다. 브라우저는 사용자에게 웹사이트가 안전함을 알려, 사용자는 사이트를 탐색하고 기밀 정보를 확인할 때 보다 안전할 수 있다.
#작동 방식
인증서를 얻으려면 서버에서 인증서 서명 요청(CSR)을 생성해야 한다. 이 과정에서 서버에 개인 키와 공개 키가 생성된다. SSL 인증서 발급자(인증 기관 또는 CA라 함)에게 보내는 CSR 데이터 파일에는 공개 키가 포함된다. 인증 기관은 CSR 데이터 파일을 사용해 키 자체를 훼손하지 않고 개인 키에 맞는 데이터 구조를 생성한다. 인증 기관은 절대로 개인 키를 볼 수 없다.
SSL 인증서를 받으면 서버에 인증서를 설치한다. 인증 기관의 루트 인증서에 연동하여 SSL 인증서의 신뢰도를 확립하는 중개 인증서도 설치한다. 해당 인증서의 설치 및 테스트에 관한 설명은 해당 서버에 따라 다르다.
아래의 이미지는 인증서 체인이다. 여기서 서버 인증서는 중개 인증서를 통해 CA 루트 인증서(이 경우 DigiCert)에 연결된다.
#SSL 인증서의 유형
다양한 유형의 SSL 인증서가 있다. 하나의 인증서가 하나의 웹사이트에 적용되는지, 아니면 여러 개의 웹사이트에 적용되는지에 따라 유형이 달라진다.
- 단일 도메인: 단일 도메인 SSL 인증서는 단 하나의 도메인("도메인"은 www.cloudflare.com처럼 웹사이트 이름입니다)에 적용됩니다.
- 와일드카드: 와일드카드 SSL 인증서도 단일 도메인 인증서처럼 단 하나의 도메인에 적용되지만, 도메인의 하위 도메인도 포함합니다. 예를 들어, 와일드카드 인증서는 www.cloudflare.com, blog.cloudflare.com, developers.cloudflare.com을 포함할 수 있지만, 단일 도메인 인증서는 첫 번째 도메인만 포함할 수 있습니다.
- 멀티 도메인: 이름이 의미하는 것처럼 멀티 도메인 SSL 인증서는 관련되지 않은 다수의 도메인에 적용될 수 있습니다. (예를 들어, www.moonlight.com, www.milktea.com, www.dnjfgkwja.com 와 같은 다수 도메인에 적용)
또한, SSL 인증서마다 유효성 검사 수준이 다르다. 유효성 검사는 신원 조회와 같은 것이며, 그 수준은 검사의 정도에 따라 다르다.
- 도메인 유효성 검사: 가장 덜 엄격하고 저렴한 수준의 유효성 검사입니다. 기업은 도메인을 관리하고 있다는 것만 증명하면 됩니다.
- 조직 유효성 검사: 보다 실무적인 프로세스입니다. CA가 담당자나 기업에 인증서를 직접 문의합니다. 이 인증서는 사용자에게 더 많은 신뢰를 제공합니다.
- 확장 유효성 검사: 조직의 배경을 완전히 검사한 후에 SSL 인증서를 발행할 수 있습니다.
#TLS Handshake
TLS 핸드셰이크는 클라이언트와 서버가 교환하는 메시지이며, HTTPS 웹에 처음 커넥션할 때 진행된다.
초기 협상 단계
- 클라이언트, 서버 간에 Client Hello, Server Hello메세지 교환
- 클라이언트가 서버에게 Cipher Suite(사용 가능 암호화, 해싱 방식 등)을 보내고 서버인증서를 요구
인증 단계
- 서버에서 공개키, 서버명, 인증기관주소 등을 포함한 인증서를 클라이언트에게 전송
- 이때, 서버는 클라이언트가 제시한 것 중 자신이 선택한 암호화 방식 및 인증서를 보냄🔗
- 필요시 클라이언트는, 인증서를 발급한 인증기관 서버에 접속하여 서버인증서의 유효성 확인
보안 채널 형성
- 클라이언트는 보안 채널 형성에 필요한 세션키를 만들기 위해,
- 서버의 공개키를 이용하여 임의의 수(Pre Master Key)를 암호화시켜 서버에게 전송하고,
- 서버는 자신의 비밀키(개인키)로 이를 해독(복호화)하게 됨
- 이때 임의의 수(Pre Master Key)로 부터 Master Key를 유도하고,
- 이 Master Key로부터 양측은 암호화, 복호화에 필요한 세션키를 생성함
상호암호화통신 시작
- 즉, 보안성이 확립된 TLS 터널 내에서 상호통신
핸드셰이크의 정확한 단계는 클라이언트와 서버에서 지원하는 암호화 알고리즘, 키교환 알고리즘에 따라 다르다.
🔗대부분 RSA 키 교환 알고리즘이 사용된다.
RSA 키 교환 알고리즘
- '클라이언트 헬로' 메시지: 클라이언트가 서버로 "헬로" 메시지를 전송하면서 핸드셰이크를 시작. 메시지 안에는 클라이언트가 지원하는 TLS 버전, 지원되는 암호화 알고리즘, 그리고 "클라이언트 무작위"라고 하는 무작위 바이트 문자열이 포함됨.
- '서버 헬로' 메시지: 클라이언트 헬로 메시지에 대한 응답으로 서버가 서버의 SSL 인증서, 서버에서 선택한 암호화 알고리즘, 그리고 서버에서 생성한 또 다른 무작위 바이트 문자열인 "서버 무작위"를 포함하는 메시지를 전송.
- 인증: 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증.
(이를 통해 서버가 인증서에 명시된 서버인지, 그리고 클라이언트가 상호작용 중인 서버가 실제 해당 도메인의 소유자인지를 확인) - 예비 마스터 암호: 클라이언트가 무작위 바이트 문자열을 공개 키로 암호화한 premaster secret 키를 서버에 전송
(클라이언트는 서버의 SSL 인증서를 통해 공개 키를 제공 받음) - 개인 키 사용: 서버가 premaster secret 키를 개인 키를 통해 복호화 (개인 키로만 복호화 가능)
- 세션 키 생성: 클라이언트와 서버가 모두 ‘클라이언트 무작위’, ‘서버 무작위’, ‘premaster secret 키’를 이용해 세션 키를 생성 (양측 모두 같은 키가 생성되어야 함)
- 클라이언트 준비 완료: 클라이언트가 세션 키로 암호화된 "완료" 메시지를 전송
- 서버 준비 완료: 서버도 세션 키로 암호화된 "완료" 메시지를 전송
- 안전한 대칭 암호화 성공: 핸드셰이크가 완료되고, 세션 키를 이용해 통신이 계속 진행
⇒ 모든 TLS 핸드셰이크가 비대칭 암호화(공개 키와 개인 키)를 사용하지만, 세션 키를 생성하는 과정에서 모두가 개인 키를 사용하는 것은 아니다. 예를 들어, 임시 Diffie-Hellman 핸드셰이크는 다음과 같이 진행된다.
- [참고] 디피헬만 키 교환 법의 작동 단계
TLS 핸드셰이크 과정에 더 자세한 설명이 필요하다면 하단의 블로그를 참고해보면 좋을 것 같다.
https://reakwon.tistory.com/106
참고자료