이것저것 준비하느라 정신없어서 다른 곳에 올려 놨던 애들 정리!
관련해서 접근을 해야 할 것 같은데 개념은 대충 알지만 남들에게 알려 줄 수 있는 수준은 전혀 아니라 정리해 본다.
참고
https://www.youtube.com/watch?v=H6lpFRpyl14&t=131s
https://jeong-pro.tistory.com/89
https://losskatsu.github.io/it-infra/ssl-auth/#
HTTPS
Hyper Text Transfer protocol security
http는 단순 텍스트를 주고 받기 때문에 서버와 클라이언트 사이에서 자원을 주고 받을 때 누군가 데이터를 가로챌 수 있다. 해당 보안상 문제점을 https 프로토콜이 해결한다. 공개키 암호화 방식을 따른다.
SSL
Secure Socket Layer
https가 텍스트를 암호화 할 수 있도록 도와주는 프로토콜이다. 프로그램간의 인증 및 데이터 암호화를 제공한다. SSL의 암호화 원리는 공개키 암호화 방식이다.
공개키 암호화 방식
데이터를 암호화, 복화화 할 수 있는 2개의 키가 존재한다.
안녕하세요 -> (1) -> dkssudgktpdy -> (2) -> 안녕하세요
dkssudgktpdy -> (2) -> 안녕하세요 -> (1) -> dkssudgktpdy
이렇게 1번 키로 안녕하세요를 암호화 한 경우에는 2번 키를 이용해서 dkssudgktpdy에 해당하는 암호문을 안녕하세요로 변경해야 한다. 똑같이 dkssudgktpdy를 2번키로 암호화 한 경우에는 무조건 1번 키를 이용해서 복호화 할 수 있다.
이런 두개의 키 중에 하나의 키(1번이라고 가정)는 모두에게 공개해서 공개키로 사용해서 전체 클라이언트에 뿌려놓고 서버에서는 나머지 하나의 키 (2번)을 개인키로 소유하고 있다.
그러면 https 요청으로 텍스트가 공개키(1번)으로 암호화해서 서버로 들어오게 되면 서버에서는 개인키(2번)으로 복호화하여 데이터를 해석한다. 그리고 서버에서 응답을 개인키(2번)으로 암호화해서 클라이언트에게 보내면 클라이언트는 다시 공개키(1번)을 이용하여 해석해서 해당 서버가 인증된 서버임을 알 수 있다.
왜 인증된 서버임을 알 수 있는걸까?
왜냐면 공개키(1번) 키를 통해서 안녕하세요 라는 데이터를 dkssudgktpdy 라고 읽을 수 있다는 개인키(2번)을 통해서 암호화 했다는 것을 알 수 있기 때문이다.
TLS
SSL의 취약성을 해결한 버전의 프로토콜이다. TLS 프로토콜 사용을 권장하지만 SSL이 역사가 깊게 함께하고 있어 용어가 혼용되어 사용된다.
CA
Certificate Authority
아주 신뢰성이 검증된 기업이다.
HTTPS 흐름
서버(네이버, 쿠팡, 우리 회사 서버)에서 https를 적용하기 위해서 공개키와 개인키를 만든다. 이하 우리 서버라고 한다.
CA 기업에게 내 공개키가 멀쩡한 우리 서버에서 만든 공개키 임을 인정해줘!하고 돈을 내고 계약을 체결한다.
CA 기업은 CA 기업 만의 공개키와 개인키를 가지고 있다. CA 그룹은 이제 개인키를 가지고 CA 기업의 이름, 우리 서버의 공개키 등의 정보를 가지고 얘네 멀쩡한 서버야!! 라는 정보를 가진 인증서를 암호화해서 우리 서버에게 준다.
그러면 우리 서버는 CA에서 발급한 인증서를 받고 우리는 검증 받은 서버군! 이라고 뿌듯해 할 수 있다.
이제 본격적으로 클라이언트랑 우리 서버가 연결하게 될텐데 본격 데이터를 보내기 전에 클라이언트는 우리 서버를 믿지 못함으로 아무 랜덤 데이터 우리 서버에게 슥 보낸다.
우리 서버는 오! 우리한테 데이터를 보내고 싶군, 우린 안정된 서버야! 라는 의미로 CA에서 발급 받은 인증서와 또 랜덤 데이터 슥 건낸다. 그러면 클라이언트 입장에서는 오! 얘네는 CA 기업 이름과 우리 서버의 공개키 등의 정보를 가진 인증서를 받을 수 있다.
여기서 클라이언트는 보통 브라우저(크롬, 엣지, 사파리..)가 되게 되는데 보통 CA들의 정보가 기본적으로 내장되어 있다. 클라이언트가 받은 인증서는 CA의 개인키로 암호화가 되어 있기 때문에 내장된 CA의 공개키를 통해 복호화 할 수 있다.
인증서를 복호화하면 우리 서버의 공개키를 알 수 있다. 이제 모든 데이터를 공개키를 통해서 암호화해서 서버에 보내느냐! 사실은 아니다. 대칭키와 비대칭키 방식을 동시에 사용한다. 왜냐면 컴퓨터에 부담이 되기 때문이다.
그래서 우리는 클라이언트와 서버가 동일한 키를 사용하게 되는 대칭키 방식을 사용하게 된다. 아니 근데 대칭키를 할거면 뭐하러 이렇게 과정을 했어! 라고 생각 할 수 있는데 그 대칭키를 공유하기 위해서 비대칭키 방식을 다시 사용하게 된다.
아까 우리 서버가 멀쩡한 서버인지 확인하기 위해서 랜덤으로 우리 서버와 클라이언트가 주고 받았던 가나다, 백곺팝 을 클라이언트에서 혼합해서 임시 키 @#$ㄹㅇ 를 만들게 된다.
@#ㄹㅇ은 공개키로 암호화되어 우리 서버에 전송되어 지고 일련의 과정을 거쳐서 클라이언트와 우리 서버에 동일한 대칭키를 가지게 된다. @#ㄹㅇ를 우리 서버에서만 개인키를 통해서 복호화 할 수 있고 다른 사람들이 가로 챌 수 없으므로 이 대칭키는 우선 안전하다.. 대칭키가 불안한 이유가 최초 대칭키를 전달하는 과정에서 누군가 그걸 가로 채가면 모두 복호화 할 수 있다.
이렇게.. 대장정의 HTTPS 통신이 이루어지게 된다.. 흥미롭다.
