143. TLS Basis
유저 데이터가 암호화되어야하는 이유
평문으로 보낸다면 해커한테 바로 노출됨.
키로 암호화 한 후 전송한다면...
해커는 봐도 모른다. 서버도 모른다.
그래서 복호화 키도 같이 보내야한다.
그러면 해커도 이 키를 탈취하면 소용없는거 아니냐
-> 대칭 키
복호화, 암호화 키 같음
해커가 키를 훔치면 위험함
비대칭 암호화
private key 와 public key 를 사용한다.
암호화 하기, 복호화 하기 기능이 분리되어있다.
비대칭 암호화 - SSH
공용키로 서버를 잠근다. -> 프라이빗 키로만 들어갈 수 있게 한다.
ssh 접속할때 프라이빗 키를 명시하고 접속한다.
서버를 추가한다면?
똑같이 공용키로 잠궈버린다.
사용자를 추가한다면?
공용키로 한번더 잠궈버린다.
비대칭 암호화 - 예시
서버에서 공용키와 프라이빗 키를 만든다 .
서버에서 만든 공용키를 받는다.
나의 대칭키를 공용키로 잠근다.
해커는 서버의 프라이빗 키가 없기 때문에 열수가 없다.
서버는 프라이빗키로 열고 사용자의 대칭키를 받는다.
이후 사용자는 대칭키로 암호화한 정보만 전달할 수 있다. (복호화를 위한 대칭키는 서버에 이미 전달 했으니까)
해커가 피싱 사이트를 만든다면?
해커가 작정하고 비슷하게 생긴 피싱 사이트를 만든다면 ?
인증서
위와 같은 사례를 방지하기 위해 서버에서 공용키만 보내는 것이 아닌 인증서도 같이 보낸다.
인증서가 위조 라면?
요즘은 브라우저가 인증서의 위조 여부를 다 판별한다.
CA Certificate authority
이들이 등장한다!
인증서의 유효성을 확인해준다.
csr 요청을 하고 나면 인증서에 서명해서 다시 보내준다.
브라우저는 유효한 CA를 어떻게 알까?
가짜 CA 을 만들어서 서명할 수도 있잖아
마찬가지로 CA들도 개인키와 공용키가 있다.
브라우저에 공용키를 내장한다 .
웹브라우저를 자세히 보면 키가 다 있는 것을 알 수 있다.
공용키와 프라이빗 키 확장자