[SK 쉴더스 루키즈] Cryptographic Failures 취약점(TLS 통신, robots.txt)

1. TLS 통신

https://docs.pexip.com/admin/certificate_management.htm

 

CA

도메인에 대한 인증을 보장해주는 역할

ex) Let's Encrypt

 

Client

웹 브라우저나 앱처럼 서버에 접속하려는 쪽

 

Server

서비스를 제공하는 쪽(웹서버 등)

 

TLS 통신 흐름 이해하기

사전 준비

0. 서버가 미리 CA에게 "내 공개키랑 도메인 정보야"라고 제출한다.

 

1. CA는 해당 서버에 대해 서명한 TLS인증서를 발급해서 서버에 업로드한다.

서버는 이걸 보관해두고 나중에 클라이언트한테 보내준다.

 

 

연결 시작

2. 클라이언트 => 서버 접속 & 신원 증명 요청

TLS Handshake의 ClientHello

 

3. 서버 => 클라이언트: TLS인증서 + 공개키 전송

 

 

검증

4. 클라이언트 => CA

CA가 정말로 신뢰가능한 CA인가? 확인.

브라우저는 OS/브라우저에 미리 깔려있는 신뢰 가능한 CA 목록(Root CA Store)을 확인한다.

 

• (기기에 저장된)CA의 공개키로 인증서의 서명을 검증
• 만료일, 도메인 일치 여부, 폐기 여부(CRL/OCSP) 등도 같이 체크
• 하나라도 문제 있으면 → "이 사이트는 안전하지 않습니다" 경고

 

 

키 교환(대칭키 만들기)

5. 검증 통과시, 세션 키를 서버 공개키로 암호화해서 전송

*세션 키: 한 번의 통신 세션 동안에만 사용하는 임시 대칭키

 

왜 공개키를 안 쓰고 세션 키를 쓰나요?

비대칭키 vs 세션 키 (대칭키) 비교

구분	비대칭키 (RSA, ECC)	세션 키 (AES 등)
키 개수	2개 (공개키 + 개인키)	1개
속도	느림 (수학 연산 무거움)	빠름 (수백~수천 배)
용도	신원 인증, 키 교환	실제 데이터 암호화
수명	길다 (인증서 유효기간)	짧다 (세션 동안만)

 

공개키 암호화는 너무 느리고 무겁기 때문이다.

(2단계에서 클라이언트는 서버의 공개키를 갖게 되었다.)

 

6. 서버가 개인키로 세션 키를 복호화하고 확인 메시지 전송

이제 클라이언트와 서버 둘 다 같은 세션 키를 갖게 됐다.

 

실제 통신

7. 이후 모든 통신은 세션 키로 암호화한다.

이제부터는 빠르고 가벼운 대칭키 암호화(AES 등)로 데이터를 주고 받는다.

 

robots.txt

봇의 disallow를 명시하는 파일이지만, 오히려 반대로 해커한테는 중요정보 경로를 알려주는 꼴이 될 수도 있다.