웹에서 보안은 사용자 정보를 보호하기 위해 필수적이다!

HTTPS와 HTTP

• HTTP : HyperText Transfer Protocol의 약자로, HTML을 전송하기 위한 통식 규약이다.

• HTTPS : S는 Over Secure Sockt Layer의 약자로, HTTPS는 보안이 강화된 HTTP라는 것을 의미한다.

  • HTTP는 암호화되지 않은 상태로 클라이언트와 서버 간 데이터를 주고 받는다.

  • HTTP를 포함한 클라와 서버의 데이터 통신은 평문 (plain text)로 오간다.
  • 암호화 되지 않은 HTTP Request라면 TCP 패킷을 누가 훔쳐 볼 수도 있다는 뜻!
  • 패킷 스니핑 : 네트워크 통신 내용을 도청하는 행위

• HTTPS와 SSL의 의미는 비슷하지만 조금 다르다고 한다.

  웹이 인터넷 위에서 돌아가는 서비스 중 하나인 것처럼,

  HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜의 일종이다.

  ​

SSL 인증서가 필요한 이유

• SSL 인증서 : 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서

  • 보통 유료로 구매해야 한다. (비쌈 ㅠㅠ)

  • 실제로 구매하고 적용하는 건 다음에…!

  • OpenSSL : 본인이 서명해서 직접 발급한 사설 인증서

    • 공개 웹사이트에서 사용하면, 브라우저에서

      이 사이트는 신뢰할 수 없는 SSL 인증서를 사용하고 있기 때문에 접속을 차단합니다.”

      라고 해버릴 수 있다.

    ​

주요 용어 정리

• 공개키/개인키 (Public / Private keys) : 브라우저와 서버 간의 메시지를 사인하고 해독하는 데 쓰인다.

  • 암호화 키, 복호화 키로 쓰일 수 있는 아주 큰 수의 쌍

  • 일반적인 시스템은 RSA 암호 시스템이라고 한다.

  • 공개키 : 메시지를 암호화할 때 쓴다.

  • 개인키 : 공개키에 대응되며, 메시지는 개인키로만 복호화 가능!

    웹 서버는 공개키를 공개하고, 브라우저가 이 공개키로 보안 채널을 구성한다.

• CA (certificatae Authority) : 공개키와 공개 DNS 이름의 연결을 보장해주는 조직.

  • 특정 공개키가 특정 사이트의 공개키라는 걸 보장한다.

    1. 클라가 HTTPS 웹 서버에 접속

    2. 웹 서버는 클라에게 인증서 제공

    3. 클라는 인증서가 유효한지 다음을 거쳐 확인

       A) 만료되지 않았는지

       B) DNS명이 클라가 접속하는 서버와 일치하는지

       C) 알려진 CA가 인증서에 서명했는지

• CSR (Certificate Signing Request) : 키를 가진 엔티티에 대한 일부 메타데이터와 공개키를 함께 묶은 데이터 형식

  • CSR은 클라가 아니라 CA가 해석한다.

    1. CA는 CSR의 유효성을 검증한 후 이를 이용해 인증서를 생성한다.

    2. 최종 인증서를 서버 관리자에게 보내준다

    3. 인증서를 설치하고 개인키는 웹 서버에 저장한다.

       ​

SSL의 동작 방법

• 먼저 기억해야 할 것!

  • 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화

  • 대칭키로 암호화된 실제 정보를 복호화할 때 사용하는 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다.

    실제 데이터 : 대칭 키

    대칭키의 키 : 공개 키

  • 컴퓨터 간 네트워크를 이용해 통신할 때의 과정

    악수 (handshake) -> 전송 -> 세션 종료\

1. 악수

   • 클라이언트와 서버는 서로 데이터를 주고 받기 전에 핸드쉐이킹을 통해 상대방이 존재하는지, 상대방과 어떻게 데이터를 주고 받을 것인지 확인한다.

   • SSL 방식을 이용할 때는, 이 때 SSL 인증서를 주고 받는다.

   • 공개키 방식의 문제

     • 공개키 방식의 암호화는 컴퓨터 자원을 많이 잡아먹기 때문에 쓰지 않는다
     • 대칭키 방식은 수신 측과 송신 측이 키를 공유해야 하므로 보안상 문제가 생긴다.

     그래서 SSL에서는 공개키와 대칭키를 혼합해서 사용한다.

     

   1. ClientHello : 클라이언트가 서버에 접속한다.
      • 클라이언트와 서버가 서로 어떤 암호화 방식을 쓸 것인지 정해야 하기 때문에, 클라에서 서버로 먼저 쓸 수 있는 암호화 방식 리스트를 알려준다.
      • 이미 SSL 핸드쉐이킹을 했다면 또 할 필요가 없다. 기존 세션을 재활용하기 위해 세션 아이디도 함께 보낸다.
   2. ServerHello : 서버는 클라이언트에게 응답한다.
      • 클라이언트로부터 받은 암호화 방식 중 서버에서 쓸 수 있는 것을 골라서 리턴한다.
      • SSL 인증서를 클라이언트로 보낸다.
   3. 클라이언트는 서버의 인증서가 CA에 의해 발급된 것인지 확인한다.
   4. 확인이 끝나면 클라이언트에 내장된 CA의 공개키를 이용해 인증서를 복호화한다.
   5. 세션키를 클라이언트와 서버가 모두 공유하면 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.

2. 세션

   • 세션은 실제로 서버와 클라이언트가 데이터를 서로 주고 받는 단계이다.

   • 정보를 상대방에게 전송하기 전에 세션 키 값을 이용해 대칭키 방식으로 암호화한다

     • 세션 키는 서로 공유하고 있기 때문에 복호화가 가능하다.

       ​

3. 세션 종료

   • 데이터의 전송이 끝나면 SSL 통신이 끝나싸음을 서로에게 알려준다.

   • 통신에서 사용한 대칭키인 세션키를 폐기한다.

     ​

참고 문헌

• 생활코딩 : HTTPS와 SSL 인증서
• Outsider’s Dev Story : HTTPS로 보안 강화하기