HTML 문서를 주고 받는 통신 규약
80번 포트를 기본적으로 사용하고 있음
서버-클라이언트 모델에 맞춰 데이터를 주고받기 위한 프로토콜
TCP/IP 위에서 동작함
상태를 가지지 않은 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성됨
단, 암호화가 되지 않은 데이터를 전송하는 프로토콜이기 때문에 보안문제가 발생할 수 있음
HTTP에 데이터 암호화가 추가된 프로토콜
->SSL 인증서(사용자가 사이트에 제공하는 정보 암호화에 이용)를 HTTP 프로토콜에 추가하여 만들어진 것
443포트를 기본적으로 사용함
SSL(보안 소켓 계층)을 이용해서 HTTP의 보안상 문제를 해결
TLS 프로토콜을 사용해서 보안을 유지, TLS는 데이터 무결성을 보장하여 데이터가 전송 중에 수정되거나 손상되는 것을 방지하며 사용자가 접속하려는 웹사이트와 통신하고 있음을 증명할 수 있는 인증기능도 있음
HTTPS는 대칭키 암호화와 비대칭키 암호화 방식 둘다를 사용함
서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고 서버 브라우저가 민감한 정보를 주고 받을 때도 도난당하는 것을 막아줌
신뢰할 수 있는 다른 기관이 존재하고 해당 기관이 서버 또는 클라리언트에 SSL인증서를 발급하여 해당 당사자를 보증
ex) 은행 사이트 진위여부를 SSL 인증서로 신뢰 판단
handshaking 과정에 비대칭키를 써서 인증서(대칭키)를 보내고
이 인증서에 대칭키를 안전하게 받았다면 연결 이후 대칭키를 사용해서 전달
handshaking 이후 대칭키를 사용하는 이유 : 비대칭키는 시간이 너무 오래 걸리며, 세션이 긴 소통방식에 적절하지 않음
HTTPS 웹사이트는 신뢰 구축을 위해 독립된 인증기관(CA)에서 SSL/TLS 인증서를 획득해야함
HTTPS 웹사이트 방문
클라이언트는 서버의 SSL/TLS인증서를 요청, 사이트의 신뢰성 검증 시도
서버는 공개키(+해당 기업의 이름, 공개키 암호화 방법)
가 포함된 SSL인증서를 회신(웹사이트의 SSL인증서는 서버 아이덴티티를 증명함)
클라이언트에서는 SSL/TLS 인증서가 유효하고 웹사이트 도메인과 일치하는지 확인
신회성 확인 후 클라이언트 측이 세션키를 랜덤으로 생성, 공개키
로 암호화하여 텍스트 파일을 서버로 전송
서버는 개인키
를 사용하여 전송받은 파일을 복호화
클라이언트와 서버 모두 동일한 세션키(대칭키)를 사용하여 메시지를 안전하게 교환
세션키
는 대칭키 암호화 방식에서 사용되는 임시 키이며 초기 SSL/TLS 인증이 완료된 후 브라우저와 웹 서버 간의 암호화된 통신을 유지
https://developer-ellen.tistory.com/189
https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/
https://100100e.tistory.com/317