[CS 스터디] HTTP, HTTPS

참고: HTTP와 HTTPS의 차이점

참고: HTTP & HTTPS | teck-interview-for-developer

 

HTTP vs HTTPS 차이점

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

 

HTTP

(HyperText Transport Protocol)

인터넷상에서 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약

• 네트워크 장치 간에 정보를 전송하도록 설계된 애플리케이션 계층 프로토콜
• 요청, 응답에 대한 규칙을 지정
• 80 포트

HTTP는 일반 텍스트 교환으로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재한다.

→ 이 문제를 해결해주는 것이 HTTPS

 

HTTPS

(HyperText Transfer Protocol Secure)

인터넷상에서 SSL 프로토콜을 이용해서 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약

• HTTP + SSL (Secure socket layer, 보안 통신망)
• 클라이언트와 서버 간 데이터 전송하기 전에 안전하고 암호화된 연결을 설정한다.
• 공개키 암호화 방식으로 메시지(텍스트)를 암호화
• 443 포트

 

HTTPS 방식도 무조건 안전한 것은 아니다.

• 신뢰 받는 CA 기업이 아닌 경우
• 자체 인증서를 발급한 경우

이때는 HTTPS를 사용해도 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의를 받는다.

 

장점

1. 보안
   • HTTP는 일반 텍스트로 권한이 없어도 인터넷을 통해 쉽게 접근할 수 있다.
   • HTTPS는 모든 데이터를 암호화된 형태로 전송하기 때문에, 민감한 데이터를 제출할 때 제삼자가 네트워크를 통해 해당 데이터를 가로채지 못한다.
2. 권위
   • 검색 엔진은 HTTP의 신뢰성이 더 낮기 때문에 보통 HTTP 웹 사이트 콘텐츠의 순위를 HTTPS 웹 페이지보다 낮게 지정한다.
   • 또 사용자도 보안 및 신뢰 요소 때문에 HTTPS 웹 사이트 및 애플리케이션을 선호합니다.
3. 성능 및 분석
   • HTTPS 웹 애플리케이션은 HTTP 애플리케이션보다 로드 속도가 더 빠르다.
   • 또 HTTPS는 참조 링크도 더 잘 추적한다. // 왜??

---

💡 SSL 프로토콜

(참고: Secure Sockets Layer 프로토콜)

SSL은 클라이언트 및 서버 사이에서 전송되는 데이터를 프라이빗 하게 유지할 수 있도록 한다.

SSL은 보안 핸드쉐이크를 사용하여 클라이언트와 서버 간 보안 연결을 시작한다.

• 핸드셰이크 동안 클라이언트와 서버는 세션에 사용할 보안 키 및 암호화에 사용할 알고리즘을 서로 맞춘다.
• 클라이언트는 서버를 인증하고, 선택적으로 서버는 클라이언트 인증서를 요청할 수 있다.
• 핸드셰이크 후 SSL은 HTTPS 요청, 서버 응답, 다음 정보들 모두를 암호화, 복호화한다. :
  • 클라이언트가 요청한 URL
  • 제출된 양식의 컨텐츠
  • 사용자 이름 및 비밀번호와 같은 액세스 권한 정보
  • 클라이언트와 서버 사이에 전송된 모든 데이터

---

HTTPS 통신 흐름

	산출물	과정
서버	개인키, 공개키	개인키, 공개키 생성
CA 기업	CA 기업 개인키로 암호화 된 인증서	기업 이름, 서버 공개키, 공개키 암호화 방법을 담은 인증서를 CA 기업 개인키로 암호화한다.
클라이언트	암호화 된 인증서	클라이언트가 서버로 HTTPS가 아닌 요청을 보내면, 서버는 응답으로 암호화 된 인증서를 반환한다.
브라우저	서버의 공개키	CA 기업의 공개키로 암호화 된 인증서를 복호화 해서 서버의 공개키를 얻는다.
클라이언트	대칭키	클라이언트와 서버의 Handshaking 과정에서 얻은 난수를 조합해서 pre-master-key(대칭키) 를 생성한다.
생성한 대칭키를 서버의 공개키로 암호화 한다.
서버	대칭키	클라이언트가 보낸 암호화 된 대칭키를 자신의 공개키로 복호화 해서 클라이언트와 동일한 대칭키를 얻는다.

→ 이후 클라이언트와 서버 통신 간 요청은 해당 대칭키를 사용해서 암호화, 복호화를 수행한다.

 

자세한 흐름

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
   • CA란?  Certificate Authority로, 공개키를 저장해 주는 신뢰성이 검증된 민간 기업
3. 계약 완료된 CA 기업은 해당 기업의 이름, A 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.
4. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건네준다.
5. 클라이언트가 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
   • CA 기업의 공개키는 브라우저가 이미 알고 있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)
6. 브라우저는 암호화 된 인증서를 (CA 기업의 공개키로) 해독한 뒤 A서버의 공개키를 얻는다.
7. 클라이언트가 A서버와 HandShaking 과정에서 주고받은 난수를 조합하여 pre-master-key(대칭키) 를 생성한 뒤, A서버의 공개키로 해당 대칭키를 암호화하여 서버로 보냅니다.
8. A서버는 암호화된 대칭키를 자신의 개인키로 복호화 하여 클라이언트와 동일한 대칭키를 획득합니다.
9. 이후 클라이언트-서버 간 통신을 할 때 주고받는 메세지는 이 pre-master-key(대칭키)를 이용하여 암호화, 복호화를 진행합니다.