[Network] SSL/TLS에 대하여

목차

🔗 HTTP와 HTTPS
- HTTP란?
- HTTP의 구조
- HTTPS란?
- SSL과 TLS의 역사

🔗 SSL/TLS의 개념

🔗 통신 계층에서의 SSL/TLS

🔗 SSL/TLS 작동방식
- 대칭키 vs 공개키 알고리즘
- SSL/TLS의 기본 원리
- Handshake의 동작순서

🔗 SSL 인증서와 CA

🔗 구글의 HTTPS 정책
- 혼합 컨텐츠란?
- 혼합 컨텐츠의 종류
- 구글의 혼합 컨텐츠 차단 정책

 

 

HTTP와 HTTPS

HTTP란?

• HyperText Transfer Protocol​
• HyperText 문서인 HTML을 전송하기 위한 통신 규약
• 80번 포트 사용
• 암호화되지 않은 방식으로 데이터를 전송 -> 메시지 감청이 쉬움
  • 유선 네트워크에서는 랜선이나 광케이블에 물리적으로 접근해 데이터를 가로챌 수 있음
  • Wi-fi같은 무선 네트워크에서는 신호를 쉽게 감청할 수 있음

 

HTTP의 구조

출처 : https://mangkyu.tistory.com/98

 

 

HTTP는 상태를 가지고 있지 않는 Stateless (상태를 가지지 않는) 프로토콜이며, Method, Path, Version, Headers, Body 등으로 구성되었다.

 

그러나 HTTP는 암호화되지 않은 평문 데이터를 전송하는 프로토콜이다. (실제 wireshark: https://www.wireshark.org 등 다양한 툴을 사용하면 데이터 패킷을 누구나 훔쳐볼 수 있다.)

 

-> 이러한 문제를 해결하기 위해 HTTPS가 등장하였다.

 

📌 HTTP 요청 구성 요소

 

[Method]

클라이언트가 수행하고자 하는 동작을 서버에 알리는 것. GET, POST, PUT, DELETE 등이 있음.

 

[Path]

요청 대상이 되는 서버의 리소스 경로. 만약 웹 페이지의 URL에서 도메인 이름 다음에 오는 부분 (/about, /contact 등)이 경로에 해당됨.

 

[Version]

사용되는 HTTP 프로토콜의 버전. HTTP/1.1이나 HTTP/2 등이 있음.

 

[Headers]

요청에 대한 추가 정보. 헤더들은 콘텐츠 유형, 인증 정보, 캐시 관리 등을 서버에 전달하는 데 사용됨

 

[Body]

주로 POST나 PUT 메소드와 함께 사용되며, 서버로 전송되는 데이터를 담고 있음.

 

HTTPS란?

• HyperText Transfer Protocol Over SSL (Secure Socket Layer)
• 즉, SSL 위에서 (Over) HTTPS가 작동함
• 보안이 강화된 HTTP -> 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원
• 443번 포트 사용
• 대칭키 암호화 방식과 공개키(비대칭키) 암호화 방식을 모두 사용

 

---

SSL과 TLS의 역사

SSL(Secure Socker Layer, 보안 소켓 계층) 인증서는 1995년에 Netscape라는 회사에 의해 개발되었다.  처음에는 SSL 1.0으로 시작했는데, 이후 보안 문제들을 개선하기 위해 2.0, 그리고 3.0으로 업그레이드가 진행되었다. Netscape가 문을 닫자, SSL의 관리는 IETF(인터넷 공학 태스크 포스)로 넘어갔다. IETF는 SSL 3.0을 기반으로 하여 TLS(Transport Layer Security) 1.0을 정의했고, 이것이 현재의 표준이 되었다.

즉, SSL 3.0과 TLS 1.0은 기본적으로 같은 것이지만, 역사적인 유래로 인해 많은 개발자들이 여전히 SSL이라는 용어를 더 많이 사용하는 경향이 있다.

 

 

SSL/TLS의 개념

기존 HTTP에서 인터넷 통신 패킷은 누구나 가로채 읽을 수 있는 일반 텍스트 형태로 전송되었다. 이러한 문제를 해결하고자 SSL이 개발되었다.

SSL은 암호화 기반 인터넷 보안 프로토콜이다. 전달되는 모든 데이터를 암호화하고, 특정한 유형의 사이버 공격도 차단해준다.

 

앞서 설명했듯이, SSL은 TLS 암호화의 전신이기도 하다. SSL은 3.0 이후 업데이트되지 않았으며, 보안 취약성 때문에 앞으로 사라지게 될 것이라고 여겨진다. 대신 TLS는 최신 암호화 프로토콜로, SSL 암호화와 혼용해서 부르는 경우가 많다. 실제 현재 제공되는 SSL 암호화는 사실상 TLS 암호화를 제공하는 것이다.

 

SSL/TLS를 사용하는 웹사이트 URL은 HTTP 대신 HTTPS가 사용된다.

 

 

 

통신 계층에서의 SSL/TLS

HTTP는 OSI 7계층 중 응용계층에 위치하고 있는, 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다. 또한 SSL/TLS는 응용계층과 전송계층 사이에서 동작하는 독립적인 프로토콜이다. SSL/TLS는 TCP의 신뢰성 있는 채널 위에서 암호화 및 인증을 제공하여, 전송되는 데이터가 보안을 유지하도록 한다.

 

응용계층의 HTTP 프로토콜에서 사용자의 데이터를 받고, 전송계층으로 캡슐화되기 이전에 SSL 프로토콜에 의해 데이터가 암호화된다. 반대 과정도 마찬가지로 복호화를 하고 응용계층으로 보낸다.

 

 

SSL/TLS의 세부 프로토콜은 다음과 같다.

프로토콜	설명
Handshake	두 통신 당사자 간의 연결을 설정할 때 보안 협상을 위한 프로토콜 (보안 매개변수 협상)
Record	협상된 보안 매개변수를 이용해 암호화, 복호화, 무결성 검증 등을 수행하는 프로토콜
Change CipherSpec	보안 매개변수를 변경하는 프로토콜 (ex. 대칭키 알고리즘을 변경할 때 이 프로토콜을 사용)
Alert	오류나 경고를 알리는 프로토콜

 

이 프로토콜은 전송 계층(TCP/UDP)과 응용 계층(HTTP, FTP) 사이에서 중요한 중간자 역할을 수행한다.

 

 

SSL/TLS 작동 방식

SSL은 웹에서 전송되는 데이터를 암호화한다. 즉 데이터를 중간에 가로채더라도 거의 복호화가 불가능하다.

SSL은 클라이언트와 서버 간 핸드셰이크(handshake)를 통해 인증이 이루어진다. 또한, 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작 여부를 확인한다.

 

 

대칭키 vs 공개키(=비대칭키) 알고리즘

대칭키 암호화는, 발신자와 수신자가 동일한 비밀키를 사용한다. 비밀키의 배송 문제가 존재하지만, 속도가 빠르다는 장점이 있다.

공개키(=비대칭키) 암호화에서 공개키는 누구나 접근할 수 있는 키이고, 비공개키(비밀키)는 특정 사람만이 가지는 키이다. 이 두 개의 키는 한 쌍으로 이루어져 있다. 데이터를 공개키로 암호화하고, 이와 쌍을 이루는 비밀키로 복호화하는 것이 비대칭 암호 통신의 원리이다. 한편, 비공개키로 암호화하고 공개키로 여는 과정이 인증서의 원리이다.

 

🔑 대칭키/공개키 개념에 대해 자세히 보러가기

 

 

SSL/TLS의 기본 원리

SSL/TLS는 클라이언트와 서버 간의 통신을 암호화하는 프로토콜로, Full Handshake 과정을 통해 세션을 생성하고, Abbreviated Handshake를 통해 세션이 이미 존재할 때 (한동안 통신을 하지 않다가) 다시 통신을 한다.

 

용어가 조금 혼동될 수 있는데, 연결은 서버와 클라이언트 간 통신의 단위를 말하며 세션은 그 연결의 다수로 이루어지며, 세션은 한 번 성립되면 다음 연결을 위해서 상태를 유지 (세션 id, negotiated cryptography parameters 등)할 수 있다. 예를 들어, 이미 한 번의 연결을 해서 암호화 방식, 인증서 교환, 세션 id등을 공유하고 연결이 끊어졌다. 이후 다음 연결에 이 세션에 대한 정보를 이용하여 별도의 과정 없이 연결을 할 수 있는 것이다.

 

핸드셰이크 과정에서는 클라이언트와 서버는 서로의 신원을 인증하고, 암호화에 사용될 키를 교환한다. 이때 대칭키 암호화와 비대칭키 암호화 방식이 모두 사용된다.

 

 

Handshake 동작순서

 

 

순서	설명	방향
1. Client Hello	클라이언트가 서버에 접속할 때 'Client Hello' 메시지를 담아 서버로 보냄. 이 때 암호화된 정보를 함께 담는데, -> 클라이언트가 생성한 난수, 세션 ID (세션을 처음 생성할때는 빈값, 이미 생성된 세션이 있다면 그 세션 ID), cipher suite (어떤 암호화 방식을 사용할지) 등이 있음. 클라이언트가 생성한 난수(랜덤값)는 나중에 비밀 데이터를 위해 사용됨. 비밀 데이터를 master secret이라고 함	클라이언트 -> 서버
2. Server Hello	서버는 서버가 생성한 난수, 세션 ID 등을 'Server Hello' 메시지와 함께 응답. 서버가 생성한 난수(랜덤값)는 역시 나중 master secret이라는 비밀값을 생성할 때 사용됨	서버 -> 클라이언트
3. Server Certificate	서버는 클라이언트에게 CA 인증서를 전달. 인증서를 통해 클라이언트는 서버가 신뢰할 만한 서버인지 확인. CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전, 클라이언트가 Handshake 과정 속 암호화에 사용할 공개키를 담고 있음.	서버 -> 클라이언트
4. Server Key Exchange	키 교환에 필요한 정보를 클라이언트에게 제공. 만약 필요하지 않다면 이 과정을 생략할 수 있음. (ex. 키 교환 알고리즘을 Diffie-Hellman으로 사용한다면 소수, 원시근 등이 필요하므로 이를 전송)	서버 -> 클라이언트
5. Certificate Request	서버 역시 클라이언트를 인증해야할 때 인증서를 요구할 수 있음 (요청하지 않을 수도 있음)	서버 -> 클라이언트
6. Server Hello Done	서버에서 필요한 내용을 모두 전송했음을 알림	서버 -> 클라이언트
7. Client Certificate	서버에서 클라이언트 인증서를 요청한 경우 인증서 송신 (안요청했으면 생략 가능)	클라이언트 -> 서버
8. Client Key Exchange	키 교환에 필요한 정보를 서버에게 제공. 이 정보를 pre-master secret이라고 하는데 이는 대칭키에 사용되는 것이므로 절대 노출되어서는 안됨. (pre-master secret : 이전에 서버로부터 받은 난수에 클라이언트가 생성한 난수를 조합해 서버에게 암호화하여 전송) ▶️ 암호화 과정: - 클라이언트는 서버로부터 받은 인증서에 포함된 공개키를 사용해 pre-master secret을 암호화함. 이 공개키는 클라이언트가 이미 가지고 있으며, 이를 통해 암호화된 정보는 오직 서버의 개인키로만 복호화 가능 - 서버가 암호화된 pre-master secret을 받으면 자신의 개인키로 복호화할 수 있음 ▶️ 키 생성: - 얻어진 pre-master secret은 클라이언트와 서버 양쪽에서 master secret을 생성하는 데 사용 - 이 master secret을 기반으로 세션 중에 사용할 대칭키가 생성. 이 대칭키는 세션의 모든 통신을 암호화하는 데 사용됨	클라이언트 -> 서버
9. Certificate Verify	클라이언트가 서버로부터 인증서 요청을 받았을 경우, 이 단계에서 클라이언트는 자신이 인증서의 소유자임을 개인키를 사용하여 증명	클라이언트 -> 서버
10. Change Cipher Spec	협상된 보안 매개변수를 적용하거나 변경될 때 서버에게 알려줌	클라이언트 -> 서버
11. Client Finished	클라이언트가 Finished 알림	클라이언트 -> 서버
12. Change Cipher Spec	클라이언트에게 보안 매개변수 변경을 알려줌	서버 -> 클라이언트
13. Server Finished	서버도 끝	서버 -> 클라이언트
14. 통신	이제 주고받은 비밀키를 통해 안전하게 통신함

 

📌 Cipher Suite

• 서버와 클라이언트가 어떤 암호화 방식을 사용할지 정하기 위해 교환하는 문자열 값
• 형식 : SSL/TLS_(키 교환 알고리즘)_(인증 알고리즘)_WITH_(대칭키 알고리즘)_(블록 암호 운용 방식)_(해시 알고리즘)
• 예시 : TLS_RSA_WITH_AES_256_GCM_SHA384
  • 키 교환 알고리즘은 RSA, 대칭키 알고리즘은 AES_256 GCM 방식, 해시 알고리즘으로는 SHA384를 사용한다는 것

 

 

 

---

 

 

SSL 인증서와 CA

SSL 인증서에는 CA 이름, 서비스 도메인, 서버 측 공개키, 유효기간 등이 적혀있다.

CA(Certificate Autority)는 클라이언트가 접속한 서버가 안전한 서버인지 인증해주는 기관으로써, 대부분 민간 기업들이 수행한다. 아래와 같은 기업들이 대표적이다.

 

출처 : https://en.wikipedia.org/wiki/Certificate_authority

 

 

 

인증서 확인하기

접속한 서버가 안전한지 (HTTPS) 그렇지 않은지 (HTTP) 브라우저에서 인증서를 확인할 수 있다.

다음은 Chrome으로 https 사이트에 접속했을 때의 확인이다. 연결이 안전하다는 아이콘과, 인증서 정보까지 확인해볼 수 있다.

 

 

 

 

한편 http인 사이트에 접속하면 크롬 브라우저가 주의하라고 알려준다.

 

 

---

 

구글의 HTTPS 정책

혼합 컨텐츠란?

초기 HTML이 안전한 HTTPS 연결을 통해 로드되지만, 다른 리소스는 안전하지 않은 HTTP 연결을 통해 로딩되는 것 (ex. 이미지, 비디오, 스타일시트, 스크립트).

HTTP, HTTPS를 혼합하여 사용해 동일한 페이지를 표시하므로 이를 혼합 콘텐츠 (Mixed Contents)라고 부른다.

이는 HTTP의 보안 문제 발생 가능성을 동일하게 가지고 있다.

혼합 컨텐츠 자세히 보기

 

 

혼합 콘텐츠의 종류

수동 혼합 컨텐츠 (Passive Mixed Contents)

• 페이지의 나머지 부분과 상호작용하지 않는 컨텐츠
• 이미지, 비디오, 오디오 등
• https://passive-mixed-content.glitch.me

 

활성 혼합 컨텐츠 (Active Mixed Contents)

• 페이지 전체와 상호작용하며 공격자가 페이지에서 거의 모든 작업을 수행
• 스크립트, 스타일시트, iframe, 기타 코드 등
• https://active-mixed-content.glitch.me

 

첨부한 링크들을 타고 들어가보면, 각각 수동 혼합 컨텐츠와 활성 혼합 콘텐츠가 있는 웹 페이지 화면이 있다.

클라이언트가 처음 서버에 접속할 때는 HTTPS를 활용해 데이터를 받아 오지만, 그 안에서 받아오는 나머지 부분이 HTTP인 경우 (즉, 혼합 콘텐츠일 경우) 크롬 브라우저가 이를 어떻게 처리하는 지 알 수 있다.

 

먼저 수동 혼합 컨텐츠의 경우 다음과 같은 warning 메시지를 볼 수 있다. 수동 컨텐츠는 안전하지 않은 HTTP로 로드되어도 최신 브라우저에서는 이런 요청을 자동으로 HTTPS로 전환하여 보안을 강화해주는 것을 알 수 있다.

 

 

반면 활성 혼합 콘텐츠의 경우 다음과 같은 메시지가 콘솔에 뜬다. 활성 혼합 콘텐츠는 HTTP요청이 크롬에 의해 차단되고, 이로 인해 해당 콘텐츠는 페이지에 렌더되지 않는다. 이때 콘솔에 HTTP 요청이 차단되었다는 메시지가 나타난다.

 

 

실제로 HTTP 요청이 불러와지지 못해 콘텐츠가 렌더되지 못한 모습이다. 콘솔창의 http 링크를 타고 들어가보면 다음과 같은 코드 등이 있는 것을 알 수 있다.

 

 

 

구글의 혼합 컨텐츠 차단 정책

현재 구글 크롬은 안전하지 않은 수동 콘텐츠 (이미지, 비디오, 오디오 등)은 자동으로 HTTPS로 업그레이드를 시도한다. 이는 사용자 데이터 보안을 강화하고, 데이터가 중간자 공격에 의해 감청되는 것을 방지하기 위함이다.

반면 활성 혼합 콘텐츠 (스크립트, iframe, 스타일시트 등) 는 크롬에 의해 기본적으로 차단된다. 이는 사용자의 보안을 위해 중요 콘텐츠가 암호화되지 않은 채 전송되는 것을 방지하기 위함이다.

또한 크롬에서는 개발자 도구의 콘솔을 통해 이러한 경고와 에러 메시지를 볼 수 있다.

 

구글의 정책 자세히 살펴보기

 

 

따라서, 개발자들은 이러한 정책을 잘 숙지하고 자신의 사이트가 모든 콘텐츠를 안전하게 전송하도록 할 필요가 있다.

 

 

 

 

---

Reference

https://o365cju-my.sharepoint.com/:p:/g/personal/01505_office_cju_ac_kr/EV_Zo-3ika9Pijru47U5Z7IBOsB8rjQatDPhjXARCJH1hA?e=qDnCX0

https://mangkyu.tistory.com/98

https://kanoos-stu.tistory.com/46

https://velog.io/@yun8565/HTTPS%EA%B3%BC-SSL

https://reakwon.tistory.com/106

https://itwiki.kr/w/TLS(SSL)