[네트워크] 2. 웹 백엔드 프로그래밍 기초 - HTTP와 HTTPS의 차이점

HTTP와 HTTPS의 차이점

참고링크

• https://brunch.co.kr/@hyoi0303/10
• https://opentutorials.org/course/228/4894

HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는다는 것이다.
즉, 데이터가 쉽게 도난될 수 있다. HTTPS 프로토콜은 SSL(보안 소켓 계층)을 사용하여 이 문제를 해결했다.
SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들어 준다.
SSL 인증서는 사용자가 사이트에 제공하는 정보를 암호화한다. 따라서 누가 데이터를 도난하더라도
암호화된 데이터기 때문에 해독할 수 없다. 이 외에도 TLS 프로토콜을 통해서도 보안을 유지한다.
TSL는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능을 제공한다.

HTTPS와 SSL

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

TCP/IP 프로토콜 위에서 SSL이 동작하고, SSL 위에서 HTTP가 동작한다.
이때 SSL위에서 동작하는 HTTP를 HTTPS라고 부른다.

SSL 디지털 인증서

클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서이다. 웹브라우저가 서버에 접속한 직후에 서버는 웹브라우저에게 인증서를 전달한다. 웹브라우저는 인증서를 보고 해당 서버가 자신이 접속하려고 했던 서버가 맞는지 확인하는 절차를 수행한다.

• 통신 내용이 공격자에게 노출되는 것을 막을 수 있다.
  이를 위해서는 암호화와 복호화가 필요하다. Key를 통해 암호화된 데이터를 복호화할 수 있다.
• 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단한다.
• 통신 내용의 악의적인 변경을 방지할 수 있다.

대칭키

암호화를 하는 쪽과 복호화를 하는 쪽이 동일한 키를 가지고 있는 것을 대칭키라고 한다.
암호화 명령어 : openssl enc -e -des3 -salt -in plaintext.txt -out ciphertext.bin;
복호화 명령어 : openssl enc -d -des3 -in ciphertext.bin -out plaintext2.txt;
openssl : openssl이라는 프로그램을 이용해서 암호화 하겠다.
enc -e -des3 : des3라는 방식으로 암호화를 하겠다.
-in plaintext.txt -out ciphertext.bin : plaintext.txt라는 파일을 가져와서 ciphertext.bib이라는 파일로 암호화 하겠다.

개인컴퓨터에서 암호화, 복호화하는 것은 문제가 되지 않는다. 그러나 멀리 있는 상대에게 암호화된 파일을 전송할 경우, 상대방이 파일을 읽을 수 있도록 KEY를 함께 보내줘야한다. 하지만, KEY는 암호화되지 않기 때문에, KEY를 도난당해 암호화 되었던 파일이 도난될 수 있다.

공개키

대칭키 방식을 개선한 방식이다. 공개키 방식은 KEY가 2개가 있다. A키로 암호화를 하면 B키로 복호화 할 수 있고, B키로 암호화하면 A키로 복호화 할 수 있는 방식이다. 이 방식에 착안하여 둘 중 하나는 비공개키이고, 다른 하나는 공개키로 지정한다.

공개키는 누구나 다운받을 수 있다. 그러나 공개키가 유출되더라도 공개키에 해당하는 비공개키를 가지고 있는 사람만이 암호화된 데이터를 복호화할 수 있다. 따라서 KEY를 배달할 때의 사고가 발생하지 않는다.

만약 비공개키를 가지고 있는 사람이 공개키를 가지고 있는 사람에게 데이터를 전송하면 어떨까? 공개키는 누구나 가지고 있기 때문에 모두가 복호화할 수 있지 않을까? 그렇다. 그런데, 비공개키로 데이터를 암호화하는 것은 암호화가 목적이 아니다. 공개키를 소유한 쪽에서 전송받은 데이터가 비공개키를 가지고 있던 쪽이 보낸 것이 맞는지 인증하기 위한 목적으로 암호화하는 것이다.

• 실습
  공개키를 이용해서 RSA라는 방식의 공개키를 만드는 명령어. 뒤에 숫자가 높을수록 안전하다.
  하지만, 그만큼 높은 성능을 컴퓨팅파워를 요구한다.

  비밀키 생성 : openssl genrsa -out private.pem 1024;
  공개키 생성 : openssl rsa -in private.pem -out public.pem -outform PEM -pubout;
  
  private.pem이라는 비밀키를 통해 public.pem이라는 공개키를 만든다는 의미이다.
  공개키를 통해 파일 암호화 : openssl rsautl -encrypt -inkey public.pem -pubin -in file.txt -out file.ssl;
  openssl을 이용해서 암호화를 하는데 public.pem이라는 파일을 사용한다는 의미이다. 공개키를 가지고있는 사람이 공개키를 통해 암호화를 하여 비공개키를 가지고 있는 사람에게 파일을 전송하기 위한 명령어이다.
  
  비밀키를 통한 파일 복호화 : openssl rsautl -decrypt -inkey private.pem -in file.ssl -out decrypted.txt
  

SSL 인증서

• 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장한다.
• SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

CA

클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 기관을 CA(Certificate Authority) 또는 Root Certificate라고 부른다. 이러한 CA는 브라우저 벤더들의 판단에 따라 CA리스트에 탑제된다.

SSL 인증서의 내용

• 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등등)
  클라이언트가 접속하려는 서버가 해당 서버가 맞는지 확인하는 정보
• 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)
  서버와 클라이언트가 암호화를 통해 데이터를 전송하기 위한 정보
  

CA를 브라우저는 알고 있다.

브라우저는 내부적으로 CA의 리스트를 미리 파악하고 있다. 즉, 브라우저의 소스코드 안에 CA의 리스트가 있다. 브라우저의 CA리스트에 포함된 CA만이 공인된 CA가 될 수 있다. 또한 각 CA의 공개키를 브라우저는 알고 있다.

SSL 인증서가 서비스를 보증하는 방법

1. 웹 브라우저가 서버에 접속할 때 서버는 브라우저에게 인증서를 제공한다.
2. 브라우저는 해당 인증서가 자신의 CA리스트에 있는지 확인한다.
3. 확인이 되었다면, 브라우저가 갖고 있는 해당 CA의 공개키를 이용해 인증서를 복호화 한다.
4. 복호화가 가능하다면, 인증서가 공인된 기관에 의해서 인증된 것이라는 의미이다.

SSL의 동작방법

공개키 방식은 보안적인 측면에서 안정적이지만 높은 컴퓨팅파워를 요구하기 때문에 성능상에 문제가 있다. 이 때문에 SSL은 암호화된 데이터를 보내기 위해 공개키와 대칭키를 혼합해서 사용한다.

실제 데이터는 대칭키를 사용하며, 대칭키를 전송할 때는 공개키를 사용한다. 대칭키는 공개키보다 성능상 우위를 갖기 때문에 반드시 필요한 경우에만 공개키를 사용하고 나머지 경우에는 대칭키를 사용하는 것이다.

네트워크 통신에는 3단계로 이루어진다.
악수 -> 전송 -> 세션종료

악수(handshake)

1. 클라이언트가 서버에 접속한다.(client hello)

   • 클라이언트가 생성한 랜덤 데이터를 서버에게 전송한다.
   • 클라이언트가 지원하는 암호화 방식을 서버쪽에 전송한다.(클라이언트와 서버가 지원하는 암호화 방식이 다를 수 있다.)
   • 이미 SSL 핸드쉐이킹을 했다면 세션 아이디를 전송한다.

2. 서버는 클라이언트에게 응답한다.(server hello)

   • 서버가 생성한 랜덤 데이터를 전송한다.
   • 서버가 선택한 클라이언트의 암호화 방식을 선택해서 클라이언트에게 알려준다.
   • 클라이언트에게 인증서를 전송한다.

3. 클라이언트는 서버의 인증서가 CA리스트에 있는 지 확인한다.
   클라이언트가 가지고 있는 해당 CA의 공개키를 이용해 서버가 전송한 인증서를 복호화한다. 복호화가 성공한다면, 해당 서버는 믿을 수 있는 대상임을 증명하는 것이다.

   인증서 안에는 서버가 생생한 공개키가 들어가 있다. 이때 클라이언트는 서버의 공개키를 획득한다. 클라이언트는 서버의 랜덤 데이터와 클라이언트의 랜덤 데이터를 조합하여 pre master secret라는 키를 생성한다.

   이후 서버의 공개키를 이용하여 pre master secret라는 키를 암호화하여 서버에게 전송한다. 이 키는 대칭키로 사용된다. pre master secret은 절대 노출되어서는 안된다.

4. 서버는 클라이언트가 전송한 pre master secret값을 자신의 비공개키로 복호화한다. 서버와 클라이언트는 모두 pre master secret을 가지고 있으며, 일련의 과정을 거쳐서 pre master secret을 master key 값으로 만든다.

   이를 이용해 최종적으로 session key를 생성한다. session key는 이후 데이터를 주고받을 때 데이터를 암호화하는 대칭키로 사용된다.
   

5. 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.

요약
1. 서버가 클라이언트에게 인증서를 전송
2. 클라이언트는 자신의 랜덤 데이터와 서버의 랜덤 데이터를 조합하여 pre master secret라는 키 생성
3. 클라이언트는 서버의 공개키로 pre master secret을 암호화하여 서버에게 전송
4. 서버는 자신의 비공개키로 pre master secret을 복호화함
5. 이후 일련의 과정을 거쳐 서버와 클라이언트는 master secret을 얻게되고 이를 이용해 session key를 생성

세션(전송)

session key사용하여 전송할 데이터를 암호화하여 전송. 상대편은 session key를 이용해 데이터를 복호화한다.
이러한 대칭키 방식을 사용하는 이유는 공개키가 컴퓨팅 파워를 요구하기 때문에 이를 해결하기 위함이다.

세션종료

SSL 통신이 끝났음을 서로에게 알려준다. 이 때 통신에서 사용한 대칭키인 세션키를 폐기한다.