HTTPS란 (SSL / TLS)

📝 HTTPS

HTTPS는 HTTP가 전송하는 데이터가 암호화되지 않은 부분을 보완한 프로토콜이다.

TLS 계층을 거치는 방식으로 HTTP를 운영하여 HTTP의 전송 메시지 바디(전송되는 데이터가 있는 부분)를 암호화시키는 것이다.

HTTP vs HTTPS (SSL / TLS)

 

HTTPS는 HTTP에 TLS 계층을 더하여 보안을 적용한 것

(SSL/TLS 프로토콜과 CA 인증 메커니즘을 통해 보안 : HTTP는 SSL/TLS 인증서를 사용 ❌ HTTPS는 SSL/TLS 인증서를 사용 🙆‍♀️)

 

📝 SSL / TLS 프로토콜은 데이터의 암호화처리와 관련이 있다.

전송되는 데이터가 민감한 정보일 경우 (ex. 로그인 정보, 개인 식별 정보, 결제 정보, 의료 정보, 금융 정보, 개인 메세지 및 통신 내용, 지리적 위치 정보, 비즈니스 기밀 등등) 그 데이터들을 암호화하여 전송하지 않는다면 다음과 같은 공격에 노출될 수 있다.

 

1. 패킷 스니핑(Packet Sniffing)

• 설명: 공격자는 네트워크에서 전송되는 데이터를 모니터링하고 가로챌 수 있다. HTTP를 사용할 경우 데이터가 암호화되지 않은 상태로 전송되기 때문에, 공격자는 전송 중인 데이터를 그대로 읽을 수 있다.
• 예시: 로그인 시 사용자가 입력한 ID와 비밀번호가 네트워크를 통해 전송되는데, 공격자가 이 데이터를 스니핑하여 탈취할 수 있다.

1. 네트워크 인터페이스 카드(NIC)의 동작 모드 변경

• 보통의 경우: 네트워크 인터페이스 카드(NIC)는 기본적으로 **"프로미스큐어스 모드(promiscuous mode)"**가 아닌 **"비프로미스큐어스 모드(non-promiscuous mode)"**로 동작한다. 이 모드에서는 NIC가 자신에게 직접 전송된 패킷만 수신하고 처리한다.
• 스니핑 시: 공격자는 NIC를 프로미스큐어스 모드로 설정하여, 네트워크를 통해 전송되는 모든 패킷을 수신할 수 있도록 한다. 이 모드에서는 네트워크 상의 모든 트래픽이 NIC에 의해 수신되고 분석될 수 있다.

2. 패킷 캡처(Packet Capture)

• 설명: 프로미스큐어스 모드에서 NIC는 네트워크 상의 모든 트래픽을 수신한다. 수신된 패킷은 스니핑 소프트웨어(예: Wireshark)로 전달되어 캡처된다.
• 동작: 캡처된 패킷은 일반적으로 데이터 링크 계층(예: Ethernet 프레임)에서부터 시작해 IP 계층, 전송 계층(TCP/UDP), 애플리케이션 계층(HTTP, DNS 등)으로 구성된다.

3. 패킷 분석(Packet Analysis)

• 설명: 캡처된 패킷을 분석하여 유용한 정보를 추출한다. 분석 과정에서는 패킷이 포함하고 있는 다양한 프로토콜 헤더 및 데이터를 조사한다.
• 민감한 정보 추출:
  • 예를 들어, HTTP를 사용하는 웹사이트로 전송된 패킷은 암호화되지 않았으므로, 공격자는 패킷에서 사용자 이름, 비밀번호, 세션 쿠키, 신용카드 정보 등의 민감한 데이터를 읽어낼 수 있다.

4. 데이터 재구성(Data Reconstruction)

• 설명: 여러 개의 패킷이 분할되어 전송되는 경우, 공격자는 이 패킷들을 재구성하여 원래의 데이터나 메시지를 복원할 수 있다.
• 예시: HTTP 트래픽에서 HTML 페이지의 여러 부분이 여러 패킷에 나뉘어 전송될 경우, 공격자는 이를 재구성하여 웹 페이지의 전체 내용을 확인할 수 있다.

5. 패킷 재전송(Packet Injection) (선택적)

• 설명: 일부 공격에서는 단순히 패킷을 캡처하고 분석하는 것뿐만 아니라, 악성 패킷을 네트워크에 주입(inject)하여 통신을 방해하거나 추가적인 정보를 유출시키기도 한다.
• 예시: 공격자가 악성 데이터나 명령어를 포함한 패킷을 주입하여 네트워크에서 공격을 감행할 수 있다.

6. 네트워크 토폴로지(망 구성방식) 에 따른 영향

• 허브 기반 네트워크: 모든 장치가 동일한 데이터 트래픽을 수신하므로, 스니퍼가 네트워크에 연결되면 모든 트래픽을 쉽게 가로챌 수 있다.
• 스위치 기반 네트워크: 스위치가 목적지 주소에 따라 트래픽을 전달하기 때문에 스니핑이 더 어려워진다. 그러나 공격자는 ARP 스푸핑, 스위치 포트 미러링 등의 방법으로 스위치 네트워크에서도 스니핑을 수행할 수 있다.

(* 출처 : ChatGPT)

 

2. 중간자 공격(Man-in-the-Middle, MITM)

• 설명: 공격자는 서버와 클라이언트 사이의 통신을 가로채어, 데이터의 내용을 수정하거나 민감한 정보를 훔쳐갈 수 있다. HTTP를 사용할 경우, 통신이 암호화되지 않으므로 공격자가 쉽게 데이터를 조작하거나 탈취할 수 있다.
• 예시: 공격자가 클라이언트와 서버 간의 통신을 중간에서 가로채어, 은행 계좌 정보나 신용카드 정보를 탈취할 수 있다.

중간자 공격(Man-in-the-Middle, MITM)은 공격자가 두 당사자 간의 통신을 은밀히 가로채거나 조작하는 공격 기법. 이 공격의 핵심은 공격자가 자신을 양쪽 당사자 모두에게 신뢰할 수 있는 통신 상대방으로 위장함으로써, 당사자들이 자신들이 안전하게 통신하고 있다고 믿게 만드는 것이다. 중간자 공격의 원리는 다음과 같이 설명할 수 있다.

1. 통신 흐름 가로채기

• 설명: 두 당사자(A와 B)가 서로 통신하려고 할 때, 공격자(M)가 이들 사이에 끼어들어 통신 흐름을 가로챈다. 이때, A와 B는 자신들이 서로 직접 통신하고 있다고 생각하지만, 실제로는 공격자가 중간에서 모든 데이터를 중계하고 있다.
• 기본 흐름:
  1. A가 B에게 데이터를 보내면, 이 데이터는 먼저 공격자 M에게 전달된다.
  2. M은 데이터를 확인한 후, 이를 B에게 전달한다. 이때, M은 데이터를 수정할 수도 있고, 그대로 전달할 수도 있다.
  3. B가 A에게 데이터를 보낼 때도 마찬가지로, 데이터는 M을 거쳐 A에게 전달된다.

2. 위장과 신뢰성 확보

• 설명: 공격자는 A와 B 모두에게 자신이 신뢰할 수 있는 상대방임을 믿게 만들어야 한다. 이를 위해 공격자는 다양한 방법을 사용하여 자신의 신뢰성을 확보한다.
• 기법:
  1. ARP 스푸핑: 로컬 네트워크에서 공격자는 ARP 캐시 테이블을 변조하여 자신을 라우터나 다른 신뢰할 수 있는 장치로 위장한다. 이를 통해 네트워크 상의 트래픽이 공격자에게로 전송되도록 만든다.
  2. DNS 스푸핑: 공격자는 DNS 서버나 DNS 쿼리를 변조하여, 사용자가 특정 도메인으로 접속하려고 할 때 공격자의 서버로 리다이렉트되도록 만든다.
  3. Wi-Fi 핫스팟 공격: 공격자는 공개 Wi-Fi 핫스팟을 설정하여, 사용자가 이 핫스팟을 통해 인터넷에 접속하게 만든 뒤, 트래픽을 모니터링하고 조작할 수 있다.

3. 통신 내용 가로채기 및 조작

• 설명: 공격자가 통신 흐름을 가로채면, 양쪽 당사자 간의 모든 데이터는 공격자를 거치게 됩니다. 공격자는 이 데이터를 가로채어 내용을 읽거나, 필요한 경우 데이터를 조작할 수도 있습니다.
• 예시:
  1. 민감한 정보 탈취: 공격자는 가로챈 데이터를 분석하여 로그인 정보, 금융 정보, 개인 식별 정보 등을 탈취할 수 있다.
  2. 데이터 조작: 공격자는 메시지의 내용을 변경하거나, 악성 코드를 삽입하여 전달할 수도 있다. 예를 들어, 사용자가 특정 웹사이트를 방문하려고 할 때 공격자는 악성 웹사이트로 리다이렉트시킬 수 있다.

4. 피해자의 통신 유지

• 설명: 중간자 공격의 핵심은 피해자가 공격을 인지하지 못하게 하는 것. 이를 위해 공격자는 통신 속도나 품질에 큰 변화를 주지 않으면서, 데이터를 신속하게 전달하려고 한다. 공격자는 양쪽 당사자 모두에게 합법적인 트래픽을 전달하므로, A와 B는 정상적으로 통신이 이루어지고 있다고 생각한다.

5. MITM 공격의 변종들

• HTTPS 스크립트 인젝션: 공격자는 HTTPS 트래픽을 중간에서 가로채어 암호화된 트래픽을 해독하거나, 스크립트를 삽입하여 웹 페이지의 내용을 변조할 수 있다.
• SSL 스트립핑: 공격자는 HTTPS 통신을 HTTP로 다운그레이드하여, 암호화되지 않은 데이터를 가로채거나 조작할 수 있다. 이를 통해 민감한 정보를 평문으로 탈취할 수 있다.
• 이메일 중간자 공격: 공격자는 이메일 서버와 클라이언트 간의 통신을 가로채어 이메일 내용을 읽거나, 발신자 또는 수신자로 위장하여 악성 이메일을 전송할 수 있다.

(* 출처 : ChatGPT)

 

3. 세션 하이재킹(Session Hijacking)

• 설명: 사용자의 세션 쿠키를 탈취하여 사용자가 로그인한 세션을 가로채는 공격. HTTP를 사용하면 쿠키가 암호화되지 않고 전송되기 때문에, 공격자가 쿠키를 훔쳐 사용자의 세션에 접근할 수 있다.
• 예시: 사용자가 로그인한 상태에서 공격자가 세션 쿠키를 가로채어 해당 사용자의 계정에 불법적으로 접근할 수 있다.

4. 피싱(Phishing)

• 설명: 공격자는 HTTP 웹사이트를 통해 가짜 로그인 페이지를 생성하고 사용자를 유도하여 민감한 정보를 입력하게 만든다. HTTP에서는 SSL/TLS 인증서가 없기 때문에, 사용자가 해당 웹사이트가 안전한지 확인하기 어렵다.
• 예시: 가짜 은행 웹사이트에 사용자가 로그인 정보를 입력하도록 유도하여 비밀번호를 탈취할 수 있다.

즉, 네트워크의 전형적인 공격인 "중간자 공격"에 취약하며, 언제든지 데이터가 도청될 수 있는 네트워크 환경에서는 네트워크를 사용하는 내내 위험하다고 볼 수 있다.

 

📝 HTTPS를 적용하며 얻게 되는 이점

암호화 메커니즘을 통해 암호학에서 핵심으로 두는 3가지 보안 기능성을 얻게 된다. (CIA)

 

1. 기밀성(Confidentiality)

교환되는 데이터를 도청해도 의미가 없게끔 데이터가 강력한 암호 알고리즘으로 암호화된다.

대칭 알고리즘을 통해 암호화와 복호화된다.

 

2. 무결성(Integrity)

정보가 중간에 변질되지 않았음을 보장하는 것이다. (중간에 중요한 정보만 가로채거나 수정하는 것을 방지)

클라이언트와 서버는 전자 서명(Digital Signature)을 통해 통신을 맺어 신뢰성을 확보한다.

 

3. 인증(Authentication)

응답자가 안전한 응답자인지 어떻게 알 수 있을까?

이를 위해서 인증서 제도를 운영한다. 인증서 기관을 통해 해당 서버가 안전한 서버라는 것을 확인할 수 있다.

 

HTTPS는 요약하면 다음을 통해 보안성을 강화한다.

1. 클라이언트는 CA 인증서를 확인해서 안전한 서버임을 확인한다.

2. 클라이언트와 서버는 공개키/개인키(비대칭 암호화)를 통해서 안전한 통신 세션을 맺는다. (대부분 RSA)

3. 공개키/개인키로 공유한 대칭키를 통해서 데이터를 암호화 복호화하여 데이터의 기밀성을 얻는다.

 

* 암호화 / 복호화에서 대칭키와 비대칭키의 차이

대칭키 vs 비대칭키

 

📝 HTTPS의 통신 절차 (TLS 핸드쉐이크)

TLS Layer

TCP/IP 세션을 연결하는 3-way handshake 다음으로 보안을 위한 SSL/TLS handshake 과정을 거친다. 

 

TLS handshake

 

TLS handshake

 

1. [클라이언트] Client Hello

TCP 연결을 위해 3-Way Handshake를 수행한 브라우저는 서버가 HTTPS를 사용하는 것을 알게 되고 아래 목록의 정보들을 전송한다.

• 브라우저가 사용하는 SSL / TLS 버전 정보
• 브라우저가 지원하는 암호화 방식 모음 (cipher suite)
• 브라우저가 순간적으로 생성한 임의의 난수
• 만약 이전에 SSL 핸드셰이크가 완료된 상태라면, 그 때 생성된 세션 아이디 (Session ID)
• 기타 확장 정보 (extension)

📘 Cipher Suite란 보안의 궁극적 목표를 달성하기 위해 사용하는 방식을 패키지 형태로 묶어놓은 것을 의미한다.

• 안전한 키 교환
• 전달 대상 인증
• 암호화 알고리즘
• 메시지 무결성 확인 알고리즘

2. [서버] Server Hello

• 브라우저의 암호화 방식 정보 중에서 서버가 지원하고 선택한 암호화 방식 (cipher suite)
• 서버의 공개키가 담긴 SSL 인증서. 인증서는 CA의 비밀키로 암호화되어 발급된 상태.
• 서버가 순간적으로 생성한 임의의 난수
• 클라이언트 인증서 요청 (선택사항)

3. [클라이언트] 서버의 SSL 인증서를 신뢰할 수 있는지 확인

대부분 브라우저에는 공신력 있는 CA들의 정보와 CA가 만든 공개키가 이미 설치되어 있다. 서버가 보낸 SSL 인증서가 정말 CA가 만든 것인지 확인하기 위해 내장된 CA 공개키로 암호화된 인증서를 복호화 해본다. 정상적으로 복호화가 되었다면 CA가 발급한 것이 증명되는 셈. 만약 등록된 CA가 아니거나, 등록된 CA가 만든 인증서처럼 꾸몄다면 이 과정에서 발각이 되며 브라우저 경고를 보낸다.

 

4. [클라이언트] 자신이 생성한 난수와 서버의 난수를 사용하여 premaster secret 생성.

웹 서버 인증서에 딸려온 웹 사이트의 공개키로 이것을 암호화하여 서버로 전송. 

 

5. [서버] 비밀키로, 브라우저가 보낸 premaster secret 값을 복호화.

복호화 한 값을 master secret 값으로 저장. 이것을 사용하여 방금 브라우저와 만들어진 연결에 고유한 값을 부여하기 위한 session key를 생성. 세션 키는 대칭키 암호화에 사용할 key이다. 이것으로 브라우저와 서버 사이에 주고받는 데이터를 암호화하고 복호화한다.

 

6. [서버 / 클라이언트] SSL handshake를 종료하고, 이제 HTTPS 통신을 시작.

브라우저와 서버는 SSL handshake가 정상적으로 완료되었고, 이제는 웹상에서 데이터를 세션 카를 사용하여 암호화/복호화하며 HTTPS 프로토콜을 통해 주고받을 수 있다. HTTPS 통신이 완료되는 시점에서 서로에게 공유된 세션 카를 폐기. 만약 세션이 여전히 유지되고 있다면 브라우저는 SSL handshake 요청이 아닌 세션 ID만 서버에게 알려주면 된다. 이 부분은 1번에서 언급되었다.

 

📙 웹서버에 SSL/TLS 인증서 설정

웹 서버에 SSL 인증서를 설정할 때 일반적으로 세 가지 파일이 필요하다.

1. SSL 인증서 파일 (Certificate): 보통 .crt 또는 .cert 확장자를 가지며, 도메인에 대한 인증 정보를 포함하고 있다. 이 파일은 서버에 설치되는 주된 SSL 인증서.
2. 개인 키 파일 (Private Key): 보통 .key 확장자를 가지며, 인증서와 짝을 이루는 비밀 키. 이 파일은 암호화된 통신을 가능하게 하며, 서버에서 절대 노출되지 않도록 주의해야 한다.
3. CA 번들 파일 (CA Bundle, Intermediate Certificate): 루트 인증서와 서버 인증서 간의 신뢰 체인을 구성하기 위해 중간 인증 기관(CA)의 인증서들을 포함한 파일이다. 이 파일은 보통 ca-bundle.crt, chain.crt 또는 intermediate.crt 등의 이름으로 저장된다.

(* 최근에 회사에서 유지보수하고 있는 홈페이지의 SSL 인증서를 교체할 때도 3파일을 Apache서버의 SSL 관련 디렉토리에 저장한 뒤 `httpd.conf` 설정 파일을 수정하였다.)

SSLCertificateFile /path/to/your/certificate.crt
SSLCertificateKeyFile /path/to/your/private.key
SSLCertificateChainFile /path/to/your/ca-bundle.crt

 

각 파일의 역할은 무엇일까?

1. SSL 인증서 파일 (Certificate)

• 역할: 이 파일은 웹 서버가 클라이언트에게 자신의 신원을 증명하기 위해 사용하는 공개 인증서. SSL 인증서에는 도메인 이름, 소유자 정보, 만료 날짜, 공개 키 등이 포함되어 있다.
• 주요 기능: 클라이언트(브라우저)가 서버에 접속할 때, 이 인증서를 사용해 서버가 신뢰할 수 있는 주체인지 확인한다.

2. 개인 키 파일 (Private Key)

• 역할: 개인 키는 SSL 인증서와 짝을 이루며, 서버에만 저장되어 있는 비밀 키. 이 키는 암호화된 통신을 해독하거나, 서버가 보내는 데이터에 디지털 서명을 추가하는 데 사용된다.
• 주요 기능: 클라이언트와의 통신을 암호화하여 제3자가 데이터를 훔쳐보거나 수정하지 못하도록 한다. 또한, 이 키는 서버가 보낸 데이터가 실제로 해당 서버에서 왔음을 보장하는 데 사용된다.

(* 클라이언트는 서버의 공개 키를 사용해 데이터를 암호화하고, 서버는 그 데이터를 자신의 개인 키를 사용해 복호화한다. 이 과정은 클라이언트가 서버로 보낸 데이터를 제3자가 중간에서 가로채더라도 내용을 해독할 수 없도록 보호한다.)

3. CA 번들 파일 (CA Bundle, Intermediate Certificate)

• 역할: CA 번들 파일에는 루트 인증서와 서버 인증서 사이에 위치한 중간 인증 기관(CA)의 인증서들이 포함되어 있다. 클라이언트가 서버의 SSL 인증서를 신뢰할 수 있도록 돕는다.
• 주요 기능: 신뢰 체인을 완성하여, 클라이언트가 서버의 SSL 인증서를 신뢰할 수 있도록 만든다. 클라이언트의 신뢰된 루트 인증서와 서버의 인증서 사이를 연결해 주는 역할을 한다.

전체적인 작동 원리

1. **서버 인증서(SSL 인증서 파일)**는 클라이언트가 서버를 신뢰할 수 있는지 확인하는 데 사용된다.
2. 개인 키는 서버와 클라이언트 간의 통신을 안전하게 유지하기 위해 사용된다.
3. CA 번들은 인증서의 신뢰 체인을 완성하여, 클라이언트가 해당 서버의 인증서를 신뢰할 수 있도록 돕는다.

 

 

 

---

📚 출처

https://www.cloudflare.com/learning/ssl/what-is-https/

https://www.cloudflare.com/learning/ssl/what-is-encryption/

https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/

https://www.cloudflare.com/learning/ssl/what-is-ssl/

HTTPS와 HTTP의 차이점. 핵심은 SSL/TLS [ 네트워크 면접질문 6 ]

TLS handshake가 일어나는 과정

HTTPS를 위한 SSL/TLS 핸드 셰이크 작동원리

HTTPS 의 동작원리