📍 기존에 알고 있었던 정의
HTTP는 간단히말해 HTML을 주고 받기 위한 프로토콜이라면
HTTPS는 기존 HTTP에 SSL 인증서를 더해 보안이 강화되면 HTTP 프로토콜이다.
📍 https를 알보기위해 알고 있어야 하는 정의
SSL
SSL(Secure Sockets Layer)은 암호화 통신과 그 암호화 통신에 사용되는 키를 공유할 수 있도록 하는 기술입니다.
즉, SSL은 인터넷 암호화 통신 프로토콜
CA (Certificate Authority) 인증기관
인증기관은 암호화시 사용되는 키를 담은 인증서를 발급하고 관리함
HTTPS
HTTPS는 기본 골격이나 사용 목적 등은 HTTP와 거의 동일하지만, 데이터를 주고 받는 과정에 ‘보안’ 요소가 추가되었다는 것이 가장 큰 차이점이다. HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화된다.
대칭키 암호화와 비대칭키 암호화
HTTPS는 대칭키 암호화와 비대칭키 암호화 사용함
- 대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
- 키가 노출되면 매우 위험하지만 연산 속도가 빠름
- 비대칭키 암호화
- 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
- 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
비대칭키 암호화는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다. 공개키와 개인키는 서로를 위한 1쌍의 키이다.
- 공개키: 모두에게 공개가능한 키
- 개인키: 나만 가지고 알고 있어야 하는 키
https 대칭키 시스템에서는 어떤 키로 암호화를 하면 같은 키로 복호화를 할 수 있음
여기서는 A키로 암호화를 하면 B키로만 복호화할 수 있다.
반대로 B키로 암호화를 하면 A키로만 풀수있다.예를 들어 네이버 서버는 개인키를 가지고 있고 다른 하나를 그냥 대중에게 공개해서 누구나 볼 수 있도록 한다.(공개키)
사용자는 이 공개키로 비밀번호를 암호화해서 네이버 서버에 보낸다.
이걸 볼 수 있는건 개인키를 가진 네이버뿐
이런 원리로 개인 정보들을 안심하고 네이버에 보낼 수 있는것
Q. 이 사이트가 네이버인것을 어떻게 증명 하냐?
A. 네이버에서 우리들에게 보내는 정보들은 그 일부가 이 네이버의 개인키로 암호화가 되어있음
우리가 네이버의 공개키로 풀어서 알아볼 수 있는건 네이버의 개인키로 암호화된 정보들 뿐
다른 사이트에서 온 정보들은 네이버의 공개키로 열어보려하면 오류가 날것이다.
Q. 그럼 어디서 검증해주는가?
신뢰할 수 있는 기관에서(CA) 네이버의 공개키만 검증해준다.
클라이언트는 이걸 기준으로 안전하게 네이버를 이용할 수 있게 된다.
공개키가 정품인지 어떻게 아는가?
서버에서는 우리에게 뿌린 공개키 이게 정품인지를 확인할 수 있어야된다.
이걸 인증해주곳은 위에서 언급했던 CA 공인된 민간기업들이 있다.
Certificate Authority 줄여서 CA
아무나 차려서 될 수 있는게 아님 엄격한 인증과정을 걸처야 CA를 할 수 있다.
📍 자주 쓰는 브라우저들의 프로그램에는 이 CA들의 목록이 내장돼있다.
CA는 세 가지 기본을 사용한다.
검증 방법 디지털 인증서를 발급 할 때. 사용 된 유효성 검사 방법은 웹 사이트의 SSL / TLS 에 포함될 정보를 결정함
TLS 증명서:
- 도메인 검증(DV) : 인증서가 적용되는 도메인 이름이 인증서를 요청한 엔티티의 제어하에 있는지 확인하기만 하면 됨
- 조직 / 개인 검증(OV / IV): 인증서에는 사업체 또는 다른 조직(OV)의 검증 된 이름 또는 개인(IV) 이 포함된다.
- 확장 유효성 검사 (EV): 인증서는 인터넷 신뢰에서 가장 높은 표준을 나타내며 CA의 유효성을 검사하기 위해 최대한의 노력이 필요합니다. EV인증서는 개인이 아닌 비즈니스 및 기타 등록 된 조직에만 발금되며 해당 조직의 검증 된 이름이 포함된다.
HTTPS 동작하는 방식
클라이언트는 아직 이 서버를 신뢰하지 못한다.
그래서 이 클라이언트와 서버는 먼저 일종의 탐색과정을 거치게 된다.
이 탐색 과정을 handshake (악수) 라고 한다.
- 먼저 클라이언트가 사이트에 접속한다.
- 접속하게 되면 어떤 랜덤 데이터를 생성해서 서버에 보낸다.
- 이걸 받은 서버는 응답으로 역시 서버측에서 생성한 랜덤 데이터
그리고 해당 서버의 인증서(SSL)를 실어 보낸다.
-
이제 클라리런트는 이 인증서가 진짜인지 브라우저의 내장된 CA들의 정보를 통해 확인하게 된다. ( 비대칭키 시스템을 사용해서 확인)
-
CA의 인증을 받은 인증서들은 해당 서버의 개인키로 암호화가 돼어있다.
- 이게 진짜라면 CA의 공개키로 복호화할 수 있는것
( 이 공개키로 복호화될 수 있는 인증서를 발급할 수 있는건 그에 대응하는 개인키를 가진 CA뿐이기 때문 )
만약 이 CA 리스트 중에 이 인증서가 해당하는 것이 없다면 브라우저 주소창에 경고 표시가 뜨게 된다.
- 이게 진짜라면 CA의 공개키로 복호화할 수 있는것
이렇게 성공적으로 복호화된 인증서에는 이 서버의 공개키가 포함돼있다.
- 이제 대칭키 방식과 비대칭키 방식이 함께 혼합되어서 사용된다.
Q.왜 비대칭키 방식이 있는데 대칭키는 왜 쓰는지? 그이유는?
비대칭키 방식으로 메시지를 암호화 및 복호화하는건 대칭키로 할 때보다 컴퓨터에 큰 부담을 주기때문
사이트를 이용할 때 주고받을 그 다량의 데이터를 비대칭키를 이용해서 일일이 암호화및 복호화하는거 무리
Q. 그럼 대칭키는 탈취당할 수 있어서 위험한거 아닌가?
그 대칭키를 공유할 때 비대칭키를 사용하면됨
아까 악수할 때 생성된 두 무작위 데이터가 있는데
클라이언트는 이 둘을 혼합해서 어떤 임시 키를 만듬
이 임시 키는 서버의 공개키로 암호화돼서 서버로 보내진 다음
양쪽에서 일련의 과정을 거쳐서 동일한 대칭키가 만들어짐
이제 이 대칭키는 서버와 해당 클라이언트 둘만 갖고 있게된다.
이후 서로 주고 받아지는 메세지들을 제 3자가 알아보기는 무리
출처 -
https://www.youtube.com/watch?v=H6lpFRpyl14
https://rachel-kwak.github.io/2021/03/08/HTTPS.html
