WEB/네트워크/ HTTPS (Hypertext Transfer Protocol Secure)

HTTPS | Hypertext Transfer Protocol Secure

[INDEX]

1. HTTPS란?

2. HTTP와 HTTPS의 차이점

3. HTTPS의 장점 (HTTP와 비교)

4. HTTPS 통신 흐름

 

---

1. HTTPS란?

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP의 확장 버전 또는 더 안전한 버전입니다.

HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정합니다. HTTP는 암호화되지 않은 데이터를 전송합니다. 즉, 브라우저에서 전송된 정보를 제3자가 가로채고 읽을 수 있습니다. 이는 이상적인 프로세스가 아니었기 때문에, 통신에 또 다른 보안 계층을 추가하기 위해 HTTPS로 확장되었습니다. HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합합니다.

 

SSL/TLS 인증서

HTTPS를 사용하려면 서버에서 SSL/TLS 인증서를 획득하고 유지 관리해야 합니다. HTTPS 웹 사이트는 독립된 인증 기관(CA)에서 SSL/TLS 인증서를 획득해야 합니다. 과거에는 대부분의 인증 기관이 인증서 등록 및 유지 관리에 대해 연간 요금을 청구했습니다. 하지만 이제는 더 이상 그렇지 않습니다.

웹 사이트는 신뢰를 구축하기 위해 데이터를 교환하기 전에 브라우저와 인증서를 공유합니다. SSL 인증서는 암호화 정보도 포함하므로 서버와 웹 브라우저는 암호화된 데이터나 스크램블된 데이터를 교환할 수 있습니다.

 

2. HTTP와 HTTPS의 차이점

HTTPS는 HTTP에서 데이터 보안 문제를 우선시합니다. 최신 시스템에서는 SSL/TLS와 함께 HTTP/2를 HTTPS로 사용합니다. HTTP/3이 더욱 발전하면 브라우저 및 서버 기술도 결국 HTTPS에 통합될 것입니다.

 

	HTTP	HTTPS
기본 프로토콜	HTTP/1과 HTTP/2는 TCP/IP를 사용 HTTP/3은 QUIC 프로토콜을 사용	HTTP 요청 및 응답을 추가로 암호화하기 위해 SSL/TLS와 함께 HTTP/2 사용
포트	기본 포트 80	기본 포트 443
용도	이전 텍스트 기반 웹 사이트	모든 최신 웹 사이트
보안	추가 보안 기능 없음	퍼블릭 키 암호화에 SSL 인증서 사용
장점	인터넷을 통한 통신 지원	웹 사이트에 대한 권위, 신뢰성 및 검색 엔진 순위 개선

 

3. HTTPS의 장점 (HTTP와 비교)

1. 보안

 HTTP 메시지는 일반 텍스트이므로, 권한이 없는 당사자가 인터넷을 통해 쉽게 액세스하고 읽을 수 있습니다. 반면, HTTPS는 모든 데이터를 암호화된 형태로 전송합니다. 사용자가 민감한 데이터를 제출할 때 제3자가 네트워크를 통해 해당 데이터를 가로챌 수 없음을 확신할 수 있습니다. 신용카드 세부 정보 또는 고객 개인 정보와 같은 잠재적으로 민감한 정보를 보호하려면 HTTPS를 선택하는 것이 좋습니다.

 

2.권위

검색 엔진은 HTTP의 신뢰성이 더 낮기 때문에 보통 HTTP 웹 사이트 콘텐츠의 순위를 HTTPS 웹 페이지보다 낮게 지정합니다. 고객도 HTTP보다 HTTPS 웹 사이트를 더 선호합니다. 브라우저는 브라우저 주소 표시줄에서 웹 사이트 URL 옆에 있는 자물쇠 아이콘을 배치하여 사용자에게 HTTPS 연결을 표시합니다. 사용자는 이러한 추가 보안 및 신뢰 요소 때문에 HTTPS 웹 사이트 및 애플리케이션을 선호합니다.

 

3. 성능 및 분석

HTTPS 웹 애플리케이션은 HTTP 애플리케이션보다 로드 속도가 더 빠릅니다. 마찬가지로, HTTPS는 참조 링크도 더 잘 추적합니다. 추천 트래픽은 광고 또는 소셜 미디어 백링크와 같은 서드 파티 소스에서 생성되는 웹 사이트 트래픽입니다. 분석 소프트웨어가 신뢰할 수 있는 트래픽 소스를 정확하게 식별하도록 하려면 HTTPS를 활성화해야 합니다.

 

4. HTTPS 통신 흐름

1. 사용자 브라우저의 주소 표시줄에 https:// URL 형식을 입력하여 HTTPS 웹 사이트를 방문합니다.
2. 브라우저는 서버의 SSL 인증서를 요청하여 사이트의 신뢰성을 검증하려고 시도합니다.
3. 서버는 public key가 포함된 SSL 인증서를 회신으로 전송합니다.
4. 웹 사이트의 SSL 인증서는 서버 아이덴티티를 증명합니다. 브라우저에서 인증되면, 브라우저가 public key를 사용하여 비밀 세션 키가 포함된 메시지를 암호화하고 전송합니다.
5. 웹 서버는 private key를 사용하여 메시지를 해독하고 session-key를 검색합니다. 그런 다음, session-key를 암호화하고 브라우저에 승인 메시지를 전송합니다.
6. 이제 브라우저와 웹 서버 모두 동일한 session-key를 사용하여 메시지를 안전하게 교환하도록 전환합니다.

 

 

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 public key와 private key를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내  public key 관리를 부탁하며 계약을 한다.
3. 계약 완료된 CA 기업은 해당 기업의 이름, A서버 public key, public key암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 private key로 암호화해서 A서버에게 제공한다.
4. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 public key로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
5. 클라이언트가 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 private key로 암호화한 인증서를 받게 된다.

CA란? : Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업
CA 기업의 public key는 브라우저가 이미 알고있다.
(세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)

 

1. 브라우저는 해독한 뒤 A서버의 public key를 얻게 되었다.
2. 클라이언트가 A서버와 HandShaking 과정에서 주고받은 난수를 조합하여 pre-master-secret-key 를 생성한 뒤, A서버의 공개키로 해당 대칭키를 암호화하여 서버로 보냅니다.
3. A서버는 암호화된 대칭키를 자신의 개인키로 복호화 하여 클라이언트와 동일한 대칭키를 획득합니다.
4. 클라이언트, 서버는 각각 pre-master-secret-key를 master-secret-key으로 만듭니다.
5. master-secret-key 를 통해 session-key를 생성하고 이를 이용하여 대칭키 방식으로 통신합니다.
6. 각 통신이 종료될 때마다 session-key를 파기합니다.

---

참고 자료

HTTP 개요 - HTTP | MDN

HTTP 개요 - HTTP | MDN

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/HTTP%20%26%20HTTPS.md

[Network] HTTP 상태 코드

[Network] HTTP 상태 코드

HTTP와 HTTPS 비교 - 전송 프로토콜 간의 차이점 - AWS

HTTP와 HTTPS 비교 - 전송 프로토콜 간의 차이점 - AWS