이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.
스택 오버플로우 원문 : https://stackoverflow.com/a/590169
SSL(Secure Socket Layer) 인증서는 서명과 검증을 통해서 데이터의 위/변조를 막고 신뢰할 수 있는 데이터를 주고 받을 수 있다.
공개키-비밀키 키페어 용례
1. 서명과 검증
비밀키로 서명, 공개키로 검증
=> SSL 인증서 발급 및 사용할 때 (무결성)
2. 암호화와 복호화
공개키로 암호화, 비밀키로 복호화
=> 서버가 클라이언트로 데이터 전달할 때 (기밀성)
이 글에서는 SSL 인증서 발급에 초점을 맞추어 서명과 검증을 중심으로 설명하고 있음.
SSL 인증서 발급
서버
서버는 서버의 비밀키, 공개키 키페어를 가짐
공개키를 클라이언트에게 넘겨주는 방법 = 인증서
인증 컨테이너
인증 컨테이너 내부에 서버의 공개키 + 서버의 메타 정보를 담음.
메타정보 : IP 주소, Domain Name, 서버 주인, email, key 생성 일자, 유효기간, 인증서의 목적 등등
CA
CA는 CA의 비밀키, 공개키 키페어를 가짐. (서버의 것과는 당연히 다르다)
CA의 인증서 생성
서버에서 생성된 인증 컨테이너는 CA (인증 기관)로 넘어가서 먼저 1.검증 과정을 거치게 됨.
인증 컨테이너의 정보들이 올바른지, 실제로 인증 정보가 해당 서버에 속해있는지 등을 검증함.
CA는 인증을 마친 후에 2. CA의 비밀키로 인증 컨테이너를 서명함.
유명한 CA 공개키들은 OS나 브라우저에 이미 기본 설치되어 있음. (없으면 다운로드 가능)
즉, 인증서 = 인증 컨테이너(서버 공개키 + 서버 메타정보)를 CA에서 검증하고 CA 비밀키로 서명한 것!
서버의 패킷 전송클라이언트가 서버에 연결될 때, 서버는 클라이언트가 필요로 하는 정보를 서버의 비밀키를 사용해 서명한 후, 인증서와 함께 클라이언트에게 전송함.
클라이언트는 받은 패킷 (= 인증서 (CA 비밀키로 인증된 인증 컨테이너) + 서버 비밀키로 서명된 요청 데이터)을 검증해야 한다.
검증
1. 메세지의 작성자와 2. 메세지가 위/변조되지 않았음을 검증한다.
클라이언트는 받은 패킷으로 총 2번의 검증을 거침.
1. 인증서를 검증
클라이언트는 브라우저나 OS에 CA 공개키를 가짐. CA 공개키를 사용해서 인증서를 검증.
-> 서버의 공개키, 서버의 메타 정보가 위/변조 되었는지 확인.
2. 서명된 데이터를 검증
그리고 검증 완료된 서버의 공개키를 사용해서 서버가 보낸 데이터를 검증. 요청한 데이터가 위/변조되었는지 확인.
의문점
Q1. 해커가 패킷을 가로채어 인증서를 바꿔치기 하거나, 데이터도 위/변조하여 보낸다면?
A1-1. 먼저 인증서가 서명되지 않았다면 클라이언트는 해당 패킷을 신뢰하지 않음.
A1-2. 그리고 CA는 인증 컨테이너의 메타 정보와 인증 요청자가 다른 경우 인증 컨테이너에 서명을 해주지 않는다.
ip 주소, 도메인 네임의 실제 주인인지 CA가 인증 컨테이너를 검증하는 과정이 있었던게 바로 그 이유
A1-1의 이유로 인해서 서명되지 않은 패킷은 버려짐.
A1-2의 이유로 인해서 위조된 인증 컨테이너는 서명이 불가능.
=> 고로 위/변조를 통한 해킹 불가능
Q2. 만약 해커가 도메인을 사서 인증서에 서명까지 받았다면?
A2. 그래도 해킹 불가능. 도메인 자체가 다르기 때문에. 특정 도메인을 위한 인증서는 해당 도메인에서만 사용 가능하다.
'ASAC' 카테고리의 다른 글
[ASAC 06] 백엔드 개발의 목적 (1) | 2024.08.28 |
---|---|
[ASAC 06] 프레임워크와 라이브러리 차이, 웹 애플리케이션 프레임워크 (3) | 2024.08.28 |
[ASAC 06] CSS 개발 확장 도구 (0) | 2024.08.27 |
[ASAC 06] Javascript 프레임워크 동작원리(2) - Bundling & Code Splitting (0) | 2024.08.27 |
[ASAC 06] Javascript 프레임워크 동작원리(1) - Javascript Transpiler (2) | 2024.08.27 |