네트워크 HTTPS

개요

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 보안 계층을 추가한 프로토콜로, 웹에서 데이터를 안전하게 주고받기 위한 암호화된 통신을 제공한다.

기본적인 HTTP는 데이터를 평문(암호화되지 않은 상태)으로 전송한다.

따라서 비밀번호, 신용카드 정보같이 민감한 정보가 유출될 위험이 있다.

이를 방지하기 위해 HTTPS는 SSL/TLS 프로토콜을 사용하여 통신을 암호화하고, 인증 및 데이터 무결성을 보장한다.

 

 

HTTP vs HTTPS

항목	HTTP	HTTPS
보안성	데이터가 평문으로 전송됨, 보안 없음	SSL/TLS로 암호화된 데이터 전송
인증	서버의 신원을 확인할 방법 없음	SSL/TLS 인증서를 통해 서버 신원 확인 가능
데이터 무결성	데이터 변조에 취약	데이터 변조 방지, 무결성 보장
포트 번호	80	443
속도	암호화가 없어 약간 더 빠름	암호화 과정으로 약간 느리지만 최적화됨
검색 엔진 최적화	SEO에 불리, "안전하지 않음" 경고 표시 가능	SEO에 유리, 브라우저에서 안전하다고 표시
사용 목적	보안이 중요하지 않은 경우	보안이 중요한 모든 경우
SSL/TLS 사용 여부	사용하지 않음	SSL/TLS 사용

 

 

HTTPS의 장점

장점	요약
보안성	전송되는 데이터가 암호화되어, 제3자가 데이터를 가로채도 그 내용을 해독할 수 없음
신뢰성	인증서를 통해 서버의 신원을 인증하여, 피싱 공격이나 중간자 공격을 방지
무결성	데이터가 전송되는 동안 변조되지 않도록 보장
SEO 혜택	구글과 같은 검색 엔진 최적화 측면에서 순위가 높아질 수 있으며, 사용자 신뢰도 향상
프라이버시 보호	사용자와 웹사이트 간의 통신을 보호하여 개인 정보를 안전하게 관리
브라우저 호환성	크롬, 파이어폭스 같은 최신 웹 브라우저들이 HTTPS를 우선적으로 지원, HTTP 사이트에는 경고 메시지를 표시
데이터 전송 보호	금융 거래나 민감한 정보 전송 시 안전성을 보장
미래 기술과의 호환성	HTTP/2, QUIC 같은 최신 웹 기술을 지원하여 더 나은 성능과 안전성을 제공

 

 

SSL(Secure Sockets Layer)

클라이언트와 서버 간의 데이터 통신을 보호하기 위해 설계된 암호화 프로토콜이다.

네트워크 상에서 전송되는 데이터를 암호화하고, 인증 및 데이터 무결성을 제공한다.

이를 통해 중간자 공격, 도청 등과 같은 보안 위협을 방지할 수 있다.

 

현재는 더 안전하고 개선된 TLS로 대체되어 SSL은 더 이상 사용되지 않는다.

그러나 많은 사람들이 여전히 SSL이라는 용어를 일반적으로 사용해 SSL/TLS 기반의 보안 통신을 의미한다.

 

 

TLS(Transport Layer Security)

SSL의 후속 버전으로, 인터넷 상에서 안전한 통신을 제공하는 암호화 프로토콜

클라이언트와 서버 간의 데이터 암호화, 인증, 데이터 무결성을 보장

오늘날의 웹 보안 표준으로 자리 잡고 있다.

 

주요 기능

• 클라이언트와 서버 간에 전송되는 데이터를 암호화, 제3자가 통신을 가로채더라도 데이터를 이해할 수 없도록 보호
• 디지털 인증서를 사용해 서버의 신원을 인증하여 신뢰할 수 있는 서버에 연결되었음을 확인
• 데이터가 전송 도중에 변경되거나 손상되지 않았음을 확인하여 데이터 무결성 보장
• 데이터가 변조되었는지 여부를 감지할 수 있으며, 변조된 데이터는 무효화

 

SSL vs TLS

항목	SSL	TLS
풀네임	Secure Sockets Layer	Transport Layer Security
개발 시기	1995년 넷스케이프(Netscape)에서 개발	1999년에 SSL의 후속 프로토콜로 개발됨
현재 버전	SSL 3.0 (1996년), 더 이상 사용되지 않음	TLS 1.3 (2018년), 현재 최신 버전
보안성	여러 가지 보안 취약점 존재 (SSL 2.0, 3.0 모두 취약)	보안이 강화된 프로토콜, 최신 TLS 1.3은 매우 안전
암호화 알고리즘	MD5, RC4와 같은 취약한 알고리즘 사용 가능	SHA-256, AES 등 강력한 암호화 알고리즘 사용
핸드셰이크 과정	더 많은 통신 라운드 필요, 성능 저하	핸드셰이크 과정이 개선되어 더 빠름
암호화 방식	고정된 암호화 알고리즘 (약한 암호화 가능)	다양한 암호화 알고리즘 선택 가능
메시지 인증 코드	핸드셰이크 메시지에서의 MAC 처리 방식 미보안	핸드셰이크 후에만 MAC 생성
이용 가능 여부	더 이상 사용되지 않음	전 세계적으로 사용되는 표준 암호화 프로토콜
사용 프로토콜	HTTPS, FTPS 등에서 과거에 사용됨	HTTPS, SMTPS, FTPS, VPN 등 다양한 프로토콜에서 사용
버전	SSL 2.0, SSL 3.0 (현재 모두 취약점 존재)	TLS 1.0, 1.1, 1.2, 1.3 (TLS 1.3이 최신)
하위 호환성	TLS와 하위 호환 가능하지만, 보안 취약	TLS는 SSL 3.0과 하위 호환성을 유지 가능하지만 보안 권장하지 않음
성능	TLS보다 느리고 비효율적	핸드셰이크와 데이터 전송 성능 최적화 (특히 TLS 1.3)

 

 

암호화

암호화는 HTTPS의 가장 중요한 특징 중 하나로, 클라이언트와 서버 간의 데이터를 암호화하여 전송한다.

이를 통해, 네트워크 상에서 데이터를 가로채더라도 공격자는 그 내용을 해독할 수 없게된다.

 

HTTPS는 대칭키 암호화와 비대칭키 암호화의 조합을 사용한다.

 

 

비대칭키 암호화

비대칭키 암호화는 공개키와 개인키 두 개의 키를 사용하는 방식이다.

공개키로 암호화된 데이터는 대응하는 개인키로만 복호화할 수 있고, 그 반대도 가능하다.

 

특징

• 공개키는 누구에게나 공개할 수 있지만, 개인키는 절대 공개되지 않고 비밀로 유지된다.
• 공개키를 통해 데이터를 암호화할 수 있으므로 대칭키 암호화의 경우처럼 안전하게 키를 공유할 필요가 없다.
• 복호화에 있어 계산이 복잡하기에 암호화는 대칭키 암호화에 비해 속도가 느리다.

 

작동 방식

1. 보내는 사람은 수신자의 공개키를 사용해 메시지를 암호화한다.
2. 이 공개키는 누구나 알 수 있지만, 오직 수신자의 개인키로만 복호화할 수 있다.
3. 수신자는 자신의 개인키를 사용해 암호화된 메시지를 복호화하여 원본 데이터를 얻는다.
4. 반대로, 개인키로 암호화한 데이터는 공개키로 복호화할 수 있다.

 

예시

1. A가 B에게 메시지를 보낼 때, A는 B의 공개키를 사용해 데이터를 암호화한다.
2. 이 데이터를 복호화할 수 있는 사람은 B뿐이다.
3. B는 자신의 개인키를 사용해 데이터를 복호화한다.
4. 이렇게 하면 A는 데이터를 안전하게 B에게 보낼 수 있다.

 

대칭키 암호화

대칭키 암호화는 하나의 동일한 키로 데이터를 암호화하고 복호화하는 방식이다.

즉, 암호화할 때와 복호화할 때 같은 키를 사용한다.

따라서 암호화된 데이터를 복호화하려면 그 동일한 키를 알고 있어야 한다.

 

특징

• 대칭키 알고리즘이 간단하고 계산 비용이 적기 때문에 비대칭키 암호화에 비해 속도가 빠르다.
• 데이터를 암호화하는 쪽과 이를 복호화하는 쪽이 동일한 키를 안전하게 공유해야 한다.

 

작동 방식

1. 보내는 사람이 대칭키를 사용해 평문을 암호화하여 암호문으로 변환한다.
2. 받는 사람이 같은 비밀 키를 사용하여 암호문을 복호화하여 원래의 평문으로 변환한다.

예시

1. A와 B가 서로 통신할 때, A가 메시지를 암호화하고 B가 이를 복호화하기 위해서는 같은 대칭키를 사용해야 한다.
2. 이 대칭키는 두 사람이 공유해야 하며, 이 키가 외부에 노출되면 통신의 보안이 손상된다.

 

비대칭키 vs 대칭키

특징	대칭키 암호화	비대칭키 암호화
키의 수	하나의 동일한 키(대칭키)로 암호화 및 복호화	두 개의 키: 공개키(암호화)와 개인키(복호화)
속도	빠름	느림
보안	키 공유 문제로 보안이 취약할 수 있음	키 공유 문제 해결, 더 높은 보안성 제공
용도	주로 대량의 데이터 암호화	주로 키 교환, 서명, 인증 등 보안에 민감한 데이터 사용
대표 알고리즘	AES, DES, 3DES	RSA, ECC, DSA
암호화/복호화 방식	동일한 키로 암호화와 복호화	공개키로 암호화, 개인키로 복호화
키 관리	키 공유가 필요하여 키 배포가 복잡함	공개키는 자유롭게 배포 가능, 개인키는 비밀로 유지

 

실제 보안 프로토콜에서는 대칭키 암호화와 비대칭키 암호화를 결합해서 사용하는 경우가 많다.

HTTPS(SSL/TLS)에서는 비대칭키 암호화를 사용해 안전하게 대칭키를 교환한다.

그 후 데이터 전송은 속도가 빠른 대칭키 암호화로 처리한다.

이렇게 하면, 비대칭키 암호화의 보안성(키 교환)과 대칭키 암호화의 성능(데이터 전송)을 동시에 활용할 수 있다.

 

 

HTTPS/SSL/TLS 통신 과정

1. 클라이언트가 서버에 HTTPS로 연결을 요청한다. ( 이때 클라이언트는 자신이 지원하는 암호화 알고리즘을 서버에 제시한다.)
2. 서버는 자신이 선택한 암호화 알고리즘과 SSL/TLS 인증서(공개키 포함)를 클라이언트에 전송한다.
3. 클라이언트는 서버가 제공한 인증서를 검증하여 서버가 신뢰할 수 있는 서버임을 확인한다. (신뢰할 수 있는 인증기관(CA)에 의해 발급되었는지, 인증서가 만료되지 않았는지, 그리고 서버의 도메인과 일치하는지)
4. 클라이언트가 랜덤한 세션 키(대칭키)를 생성하고 서버의 공개키로 암호화하여 서버에 전송한다. (클라이언트는 서버의 공개키로 세션 키를 암호화하기 때문에, 이 세션 키는 오직 서버의 개인키로만 복호화할 수 있다.)
5. 서버는 자신의 개인키를 사용하여 클라이언트가 보낸 세션 키(대칭키)를 복호화한다.
6. 이 과정이 완료되면, 클라이언트와 서버는 동일한 대칭키를 공유하게 된다.
7. 이후의 모든 데이터 전송은 대칭키 암호화로 이루어진다.
8. 원하는 데이터 통신이 완료되었을 경우 클라와 서버는 세션을 종료한다.
9. 사용된 대칭키는 더 이상 유효하지 않으며, 새로운 통신이 필요할 경우 다시 1번부터 시작

 

 

대칭키 암호화 알고리즘

알고리즘	설명	특징	사용 사례
AES	Advanced Encryption Standard. 가장 널리 사용되는 대칭키 암호화 방식	128, 192, 256비트 키 길이를 지원. 빠른 속도와 강력한 보안	HTTPS, VPN, 파일 암호화, 메신저 등
3DES	Triple Data Encryption Standard. 3번의 DES 암호화 과정	AES보다 느리며, 보안이 덜 강력. 현재는 많이 사용되지 않음	구 버전 암호화 시스템

 

 

비대칭키 암호화 알고리즘

알고리즘	설명	특징	사용 사례
RSA	Rivest–Shamir–Adleman. 가장 널리 사용되는 비대칭키 암호화 방식	2048, 3072비트 키 길이 사용. 보안은 강력하지만 속도는 느림	TLS 핸드셰이크에서 대칭키 교환에 사용
ECC	Elliptic-Curve Cryptography. RSA보다 짧은 키로 높은 보안 제공	ECC 256비트는 RSA 3072비트와 동일한 보안. 자원 소모 적음	모바일, IoT, HTTPS, TLS 1.2 및 1.3 사용

 

 

해시 알고리즘

알고리즘	설명	특징	사용 사례
SHA-256	Secure Hash Algorithm 256. 고정 크기(256비트) 해시 생성	충돌 가능성이 매우 낮고 보안성이 높음. 데이터 무결성 보장	HTTPS, 디지털 서명, 데이터 검증
SHA-1	Secure Hash Algorithm 1. 과거에 널리 사용되었지만 보안 취약	현재는 더 이상 사용하지 않음	과거 인증서 서명, 데이터 무결성 확인

 

 

키 교환 알고리즘

알고리즘	설명	특징	사용 사례
DH	Diffie-Hellman. 비대칭 방식으로 대칭키 교환	보안성이 강하지만 성능이 떨어짐.	HTTPS, VPN에서 세션 키 교환
ECDH	Elliptic-Curve Diffie-Hellman. ECC를 기반으로 한 키 교환 방식	더 적은 자원으로 DH보다 효율적이고 높은 보안성 제공	HTTPS, TLS 1.2 및 1.3에서 널리 사용됨

 

 

메시지 인증 코드 (MAC) 알고리즘

알고리즘	설명	특징	사용 사례
HMAC	Hash-based Message Authentication Code. 해시 함수와 대칭키를 사용한 메시지 인증 코드	데이터 무결성 및 인증 보장. SHA-256과 자주 결합하여 사용	HTTPS, API 인증, 데이터 무결성 검증