HTTPS VS HTTP

HTTP

웹 상에서 클라이언트와 서버 간에 하이퍼미디어 문서를 교환하는 기본적인 통신 방식으로 header와 body로 구성된 메세지를 통해 정보를 교환한다.

웹 브라우저와 웹 서버간 데이터 통신을 위한 기본적인 프로토콜로 해당 프로토콜로 데이터를 전송할경우 암호화가 진행되지 않은 평문 데이터를 주고받는다.

HTTPS

HTTP에 Secure가 붙은것으로 보안계층(SSL/TLS)를 추가한 프로토콜이 데이터 통신을 암호화하여 진행한다.

1. 내가 웹사이트에 보내는 정보를 훔쳐보지 못하도록 암호화(보안계층에서 진행)를 진행한다. (클라 -> 서버 또는 반대의 방향에서 이를 방지하게된다.)

2. 서버 신원 확인을 진행하여 신뢰 가능한 사이트인지 확인이 가능하도록 해준다. (검증된 사이트만 Secure이 붙게 된다)

대칭키, 비대칭키

대칭키

하나의 동일한 키를 활용해 양쪽 모두 데이터를 암호화,복호화를 진행하는것

하지만 데이터를 처음 보낼때 해당 대칭키에 한 정보를 보내야하는데 이때 시점에서 키가 노출될경우 암호화의 의의가 사라지게된다.

 

비대칭키(공개키)

주고받는쪽이 데이터를 암호화, 복호화를 진행할때 서로 다른 키(공개키, 개인키)를 사용하는 경우 서로 한쌍이지만 서로 다르기때문에 비대칭키 라고도 불리운다

개인키를 서버가 보관하고 웹상엔 공개키를 사용해 해당 키를 뿌려버린다

공개키로 암호화 할경우 개인키로만 복호화가 가능해지며 반대의 경우도 마찬가지다.

즉, 서로 데이터를 주고받을경우 갖고있는 공개키로만 데이터를 풀어볼수 있기에 이를 통해 내가 요청한 사이트인지 확인이 가능하다.

서버의 신원을 확인하기 위해서 서버가 자신의 개인키로 서명한 인증서를 클라이언트에 제공하고 클라이언트는 서버의 공개키로 이를 검증한다.

 

HTTPS의 공개키가 정품인지 확인을 위해선 각각의 브라우저에 내장된 CA가 확인한다.

 

핸드셰이크 과정

1. 클라 -> 서버에 무작위 데이터 전송 - 클라가 지원하는 TLS버전, 랜덤값, 암호화 방식 목록 전송

2. 서버 -> 클라에 무작위 데이터 및 서버 인증서 전송 - 선택된 TLS 버전 및 암호화 방식, 서버 랜덤값 

3. 클라는 서버가 제공한 인증서의 서명을 검증(브라우저는 CA 인증서 목록을 내장하며 CA의 개인키로 인증서에 서명이 되어있으며 클라이언트는 CA의 공개키로 서명을 검증)

4. 문제가 없을경우 클라이언트는 클라이언트와 서버의 서로 공개키를 사용해 세션키를 생성, 해당 키를 통해 통신을 암호화한다.

 

 

SSL/TSL

대칭키와 비대칭키 방식이 혼합되어서 사용된다.

비대칭키 방식으로 암호화 및 복호화를 진행하는건 대칭키로 할떄보다 부담되며 비 대칭키 방식으로 메세지를 암호,복호화 할경우 

데이터는 대칭키로 암호화를 진행하며 대칭키를 공유할때 비대칭키를 사용한다.

1. 암호화 (도청방지)

2. 통신내용 변경 방지 (위조방지 -> 메시지 인증 코드(MAC) 또는 해시 함수를 통해 변경여부 검)

3. 신뢰 가능한 사이트인지 확인(피싱방지 -> CA)

 

SSL, secure Sockets Layer  (보안소켓계증) -  디지털 인증서라 불리우며 사용자와 서버 (웹사이트) 사이의 보안소켓 계층을 의미한다 (현재는 TLS로 대체되었다)

TLS, Transport Layer Security  (전송 계층 보안) - HTTP에 보안계층을 추가한것으로 HTTP를 TLS로 암호화한것

 

CA (Certificate Authority)

클라이언트가 접속하려는 서버가 실제로 의도한 서버인지(신뢰 가능한 서버인지) 확인 해주는 민간업체로 서버에 대한 디지털 인증서를 발급한다.