웹 저장소 및 HTTPS, CORS 보안(5) - HTTPS

✅ HTTPS

웹 통신 내 요청, 응답에 대한 암호화
HTTPS(HTTP Secured, TLS): 웹 통신 내 end to end 회선 보호

SSL(Secure Sockets Layer) 혹은 TLS(Transport Layer Seucurity) 프로토콜을 통해 HTTP 보안 강화

✅ HTTPS 목적

요청을 보내고, 응답을 받는 두 주체(end to end)만 HTTP 요청 및 응답을 읽을 수 있게 암호화

목적: MITM(Man In The Middle) 공격 방지

심화 : MITM (Man-In-The-Middle) 공격 종류
🔹스니핑(sniffing, 도청): Wireshark 를 통해 여러분의 모든 웹 서핑 패킷 도청 가능
보안되지 않았다는 것은 AP;access pointer 와 연결된 컴퓨터 사이에 암호화 복호화 되지 않음을 의미
-> HTTP로 요청했을 경우 스니핑 가능

HTTPS를 사용하면 어떤 요청을 했는지 알 수 있지만 그 안의 내용은 알지 못한다.

✅ HTTPS 보안 적용 방식

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식의 장점만 사용한다.

• HTTPS 는 암호화 방식 2개 모두 사용 : 비대칭키(Public, Private), 대칭키(’세션키’로 부름)
• 서버와 클라이언트가 비대칭키를 주고받아, 그걸 통해 생성한 대칭키('세션키'로 부름)로 암호화 통신
• 서버를 클라이언트에게 비대칭키 중 공개키를 그냥 전달하지 않고 CA 인증기관의 인증 후 전달

CA: SSL인증서를 발급하는 기관, 신뢰할 수 있는 기관
    - 인증 기관에 의해 인증된 서버인지 = 인증기관에 의해 암호화된 '서버의 공개키'인지
    - 피싱 방지: 클라이언트가 실제로 도메인을 소유하고 있는 올바른 서버와 통신하고 있는지 확인 목적
    - 해당 웹 서버의 주소, 소유주, 이메일 주소, 회사 및 개인 정보 등을 CA가 전자문서화한다.

왜 HTTPS는 비대칭키와 대칭키 두개를 사용하나?

[비대칭키(public key) 암호화]

장점: 공개키는 누구나 볼 수 있고 노출되어도 안전
단점: 연산 속도가 느리다

노출되어도 안전한 공개키를 클라이언트에게 공유하여 암호화 통신을 위한 시작을 연다

비대칭 암호화는 갑을 관계를 내포한다 갑(비공개키)과 을(공개키) -> 갑(서버), 을(클라이언트); 을이 public key를 가져간다.

• 1:N = 단일 서버: 다수 클라이언트
  • 1 = 단일 서버만 사용 가능한 키: 비공개키(private key)
  • N = 다수 클라이언트라면 모두 사용 가능한 키: 공개키(public key)
• 비대칭키는 비공개키-공개키 pair를 이룬다.

 

[대칭키(private key) 암호화]

장점: 암호화/복호화 연산속도가 빠르다
단점: 하나의 키만 사용하므로 해당 키가 노출되면 매우 위험

연산 속도가 빨라 매번 클라이언트와 서버가 요청/응답을 주고 받을 때 성능 영향을 안준다.

---

HTTPS 동작 원리

동작 원리 등장하는 주체 2가지 종류: 2개의 비대칭키(public key)+ 1개의 대칭키(private key)

• 2개의 비대칭키 pair가 있다 (서버, CA 비대칭키 pair)
  1. 서버의 공개키 + 서버의 비공개키 : HTTPS 적용하려는 웹 서버가 갑 + HTTPS 통신할 클라이언트가 을
     • 서버의 공개키는 CA의 비공개키로 암호화하여 클라이언트에게 전달
  2. CA의 공개키 + CA의 비공개키: 인증을 해주는 주체인 CA가 갑 + 인증을 받아야하는 많은 웹 서버가 을

 

[그림으로 보는 HTTPS 동작 원리]

참고: HTTPS 동작원리 설명 글

handshake -> 전송(세션 단계) -> 세션 종료 단계로 이루어진다.

1. handshake과정: 아래 그림과 같은 과정을 거쳐서 session key를 공유하는 걸로 과정이 종료된다.
2. 전송 단계: 실제 데이터를 session key값을 이용해서 대칭키 방식으로 암호화해서 주고 받는다
3. 세션 종료: SSL통신 끝난 후 session key 폐기

 

[handshake 과정]

(A) 비대칭키 (서버 공개키 / 비공개키) + (B) 비대칭키 (CA 공개키 / 비공개키) + (C) 대칭키 (= 세션키)

• 사진에서 AAA, BBB는 각각 클라이언트와 서버가 생성한 랜덤 데이터이다
  • 이 데이터를 가지고 pre master key를 생성해서 Session key(비대칭키)로 사용한다.
  • session key는 대칭 키이므로 절대 외부에 노출되면 안된다.

 

[세션 단계]

클라이언트가 아이디, 패스워드와 같은 정보를 서버에게 전송하기 전에 session key값을 이용하여 대칭키 방식으로 암호화한다.

서버도 session key값을 알고 있기 때문에 암호화된 정보를 복호화할 수 있다.

• 외부에서는 sessoin key를 모르기 때문에 클라리언트와 서버가 어떤 데이터를 주고 받는지 알 수 없고, 응답을 주고 받는 두 주체만(end to end) session key로 복호화해서 알 수 있다.

 

[세션 종료]

데이터 전송이 끝나면 SSL통신ㄴ이 끝났음을 서로에게 알려주고, 사용한 대칭키(session key)를 폐기한다.

세션의 수립과 종료는 아주 짧은 시간에 일어나기 때문에, 그동안 암호가 해독된다고 해도 대칭키는 아마 폐기된 상태이다.

 

HTTPS 에서 절대 노출 되면 안되는 키
- 비대칭 키 중 CA 비공개키와 서버 비공개키
- 대칭키: session key

---

여기서부터는 이전에 배운 프록시 내용과 결합하여 정리한 글입니다.
프록시 관련 글: https://mystudylog.tistory.com/123

프록시를 사용해서 서버의 비공개키를 쉽게 관리하자

HTTPS 통신하기 위해서는 서버가 서버의 비공개키를 가지고 있어야한다. 트래픽이 많아지면 분산 서버로 운영하게 될 것이다.

그렇게 되면 서버 여러 대에 모두 비공개키를 지니고 있어야하므로 관리가 어려워진다

이때 이전에 배웠던 프록시를 서버 앞에 두어 프록시만 비공개키를 지니도록 하면 서버는 비공개키를 가지고 있지 않아도 HTTS통신을 할 수 있다.

웹 브라우저가 프록시와 소통에 성공하면 프록시는 서버에 요청을 뿌려주면 된다.