[네트워크]HTTPS / 공개키와 대칭키

HTTP와 HTTPS의 등장

• HTTP는 통신 시 정보를 평문으로 주고 받는다. TCP/IP는 도청 가능한 네트워크 이므로 패킷을 수집하여 정보를 가로챌 수 있다.
  • HTTPS: 통신을 암호화하는 프로토콜과 조합해 통신 내용을 암호화 할 수 있다. HTTP 메시지에 포함된 콘텐츠만 암호화 하는 것이다.
• 통신 상대를 확인하지 않아 웹 서버에 접근 제한이 없는 경우 request가 오면 상대가 누구든지 response를 반환해야 한다. 이로 인해 DoS 공격이 발생할 수도 있다.
  • SSL은 상대를 확인하는 수단으로 인증서를 제공한다. 신뢰할 수 있는 제 3 기관에 의해 발행된 것으로 서버나 클라이언트를 증명한다.
• 완전성(정보의 정확성)을 증명할 수 없다. 서버 또는 클라이언트에서 수신한 내용이 송신 측에서 보낸 내용과 일치함을 보장할 수 없기 때문에 request/response발신 후 변조(중간자 공격)되더라도 이 사실을 알 수 없다.
  • SSL에는 인증, 암호화, 다이제스트 기능이 포함되어 있어 이를 방지할 수 있다.

이를 보완하기 위해 서버와 브라우저 간에 보안 세션이 먼저 설정되도록 HTTPS가 도입되었다. SSL및 TLS와 같은 암호화 프로토콜은 HTTP를 HTTPS로 전환한다.

• HTTP
  • 80번 포트
  • 안전하지 않음
  • 애플리케이션 계층에서 작동함
  • 암호화 기능이 없음
  • 인증서를 필요로 하지 않음

HTTPS = HTTP + 암호화 프로토콜(SSL)

HTTPS는 응용 계층의 새로운 프로토콜이 아니라, HTTP 통신의 소켓 부분을 SSL or TLS 라는 프로토콜로 대체한 것이다. HTTP는 TCP와 직접 통신하지만, HTTPS는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. 그리고 이 SSL을 이용해 암호화와 증명서, 안정성 보호를 이용할 수 있게 된다.

HTTPS에서 보안을 달성하기 위해 PKI 방식을 사용한다. 공개 키는 여러 웹 브라우저에서 사용할 수 있고 개인 키는 특정 웹 사이트의 웹 서버에서 사용할 수 있다. 공개 키의 배포는 브라우저에서 유지 관리하는 인증서를 통해 이루어진다. 브라우저 설정에서 이러한 인증서를 확인할 수 있다. 기본적으로, 보안 세션 설정은 서버와 브라우저 간의 하이퍼 텍스트 교환 전에 수행된다.

• HTTPS
  • 443번 포트
  • 안전함
  • 전송계층에서 작동함(정확히는 응용 계층에서 SSL로 데이터를 전송하고 SSL은 받은 데이터를 암호화하여 전송계층으로 전달하는 방식을 사용한다. 송수신시에 http는 TCP(전송계층)을 SSL로 인식하고 TCP는 SSL을 http로 인식하기 때문에 기존 방식을 그대로 사용할 수 있다.)
  • 암호화 기능을 제공함
  • 인증서를 필요로 함
• 단점 및 극복 방안
  • 암호화 통신은 CPU와 메모리 등 리소스를 더 많이 요구한다.
  • 하지만 최근 하드웨어의 발달로 HTTPS를 사용하더라도 속도 저하가 거의 발생하지 않으며 HTTP 2.0을 함께 이용하면 HTTPS가 HTTP가 더 빠르게 작동한다. 따라서 최근엔 민감한 정보는 물론, 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌고 있다.

 

대칭키와 공개키

대칭키

암호화와 복호화에 같은 암호키를 사용함.

속도가 빠르나 대칭키 전달 과정에서 해킹 위험에 노출됨

공개키

암호화와 복호화에 사용하는 암호키를 분리함

자신이 가지고 있는 고유한 개인키로만 복호화할 수 있는 공개키를 대중에게 공개함

1. A가 웹 상에 공개된 B의 공개키를 이용해 평문을 암호화하여 B에게 보냄
2. B는 자신의 비밀키로 복호화 후 A의 공개키로 응답을 암호화하여 전송
3. A는 자신의 비밀키로 복호화 진행

해킹 위험은 적으나 속도가 느림.

SSL의 탄생의 시초 = 공개키 + 대칭키

처음에 대칭키를 주고받을 때에만 공개키 방식을 사용하고 데이터를 주고받을 때는 대칭키 방식을 취하는 것

1. A가 웹 상에 공개된 B의 공개키를 이용해 대칭키를 암호화하여 B에게 보냄
2. B는 비밀키로 복호화 후 얻은 A의 대칭키를 이용해 평문을 암호화하여 A에게 보냄
3. A는 대칭키로 복호화 진행
4. 해당 대칭키 사용

SSL

인증서 역할

1. 클라이언트가 접속한 서버가 신뢰할 수 있음을 보장
2. SSL 통신에 사용할 공개키를 클라이언트에게 제공함

서비스 보증 방법

1. 브라우저가 서버에 접속하면 서버는 제일 먼저 인증서를 제공함
2. 브라우저는 인증서를 발급한 CA가 자신이 갖고 있는 CA리스트에 있는지 확인함
3. 있다면 해당 CA의 공개키로 인증서를 복호화함
4. 복호화되면 신원을 보장함

동작 방법

• 공개키 암호 방식은 알고리즘 계산 방식이 느리다.
• 따라서 SSL은 암호화된 데이터를 전송하기 위해 이를 혼합하여 사용한다.

통신 과정

https://wayhome25.github.io/cs/2018/03/11/ssl-https/

https://bravenamme.github.io/2019/12/03/https-2/

• 핸드쉐이크 → 세션 → 세션 종료의 과정을 거친다
• SSL 헨드쉐이크와 목적
  • 프로토콜 버전 번호 교환
  • 양쪽이 아는 pre master secret키 생성 및 교환
  • 신원 인증
  • 채널을 암호화 하기 위한 임시 세션 키 생성