SSL 인증서, TLS(전송계층보안)

SSL 인증서의 개념

• ssl이 버전이 바뀜에 따라 TLS로 부름

• HTTPS는 대칭 키 암호화 방식으로 데이터를 암호화 복호화 진행함. 그러면 핵심은 대칭 키를 어떻게 공유 할지임
• 암호화되지 않은 통신망에서 대칭 키는 어떻게 공유할 것인가?? ⇒ 공개 키 암호화 방식으로 대칭 키를 서로 공유하자

• 인증서란, 결국 대칭키 교환 과정에서 사용 되는 서버의 공개 키를 인증 기관에서 서명(인증)해서 인증서로 만든 것임

대칭키 교환 과정(개략적. 인증서 개념 포함 x)

• 공개 키 암호화 방식을 이용하여 암호화되지 않은 통신망을 통해 대칭 키를 공유할 수 있도록 함

1. 웹 브라우저는 서버에게 공개 키를 달라고 함. 서버는 자신의 공개 키를 보낸다

2. 웹 브라우저는 대칭 키를 생성하여 서버의 공개 키로 암호화 한 후 서버에게 보낸다

3. 서버는 웹브라우저가 보내 온 암호화된 대칭 키를 자신의 개인 키로 복호화 하여 대칭 키를 얻는다.

• 이 과정에서 공유된 대칭 키를 세션 키라고 함

• 그런데 문제는, 서버가 보내 온 공개 키가 진짜 그 서버의 것인지 어떻게 믿냐. 중간에서 누가 바꿀 수도 있으니까..! ⇒ 중간자 공격

중간자 공격

• Man in the middle attack

• 공격자가 통신 객체가 전송하는 공개 키를 자신의 공개 키로 바꾸는 것

• 인증서는 다음의 정보들의 조합임
• 서버의 공개 키
• 도메인 이름을 비롯한 서버의 여러 정보들
• 위의 두 가지를 합한 것을 인증 기관이 자신의 개인 키로 서명한 값

• 인증 기관(CERTIFICATE AUTHORITIES, CA)
• 인증서를 발행하는 신뢰할 수 있는 기관, 상업적인 기관임!
• CA는 서버가 제출한 서류(CSR)를 심사하여, 자신(CA) 의 개인 키로 서명한 값을 추가한 인증서를 생성하여 서버에게 돈을 받고 준다. 그것도 매년 혹은 격년.(1년짜리 인증서, 2년짜리 인증서...)
• 무료 인증서와 유료 인증서는 차이가 없음.
• 각 운영체제와 웹브라우저는 유명한 CA의 인증서(공개 키)를 미리 가지고 있음. 그래야 서버에서 해당 인증서가 왔을 때, 전자 서명 방식으로 된 서명을 가지고 있는 공개 키를 통해서 확인을 할 수 있으니까.

인증서

• .PEM : X.509 v3 파일의 한 형태로 Privacy Enhanced Mail은 Base64 인코딩된 ASCII text file임. 바이너리를 base64 인코딩 한것

• key : 개인 또는 공개 키, 대개 pem 형식

• crt, cer : 인증서를 나타내는 확장자로써 공개키를 인증기관에 제출하고 인증기관에서 서명한 값을 pem으로 만든 것

• csr : Certificate Signing Request는 인증기관(ca)에 인증서 발급요청을 하는 파일이며 그 안에는 내 공개키 정보와 사용하는 알고리즘 정보 등이 들어 있음

• star 인증서 라는 것도 있음. 원래는 도메인 별로 인증서 하나 씩 할당 해야 하는데 *.google.com 이런 식으로 도메인 여러 개를 묶어서 인증서 제공 하는 것. 일반 인증서에 비해 매우 비쌈

• root 인증서(최상위 인증기관이 인증한 인증서). 최상위 인증기관이 있고, 그 밑에 tree 형식으로 하위 인증기관이 있는데 root가 인증하면 하위 인증기관이 그것을 활용하여 인증해주고 그것을 이용함.

전송 계층 보안(TLS : Transport Layer Security)

• HTTPS의 S 암호화를 담당

• 과거에 SSL(Secure Sockets Layer)라고 불리었음

• 전송 계층 보안, 전송 데이터 암호화

• 물리적으로 존재하는 계층이 아니라 TCP/ UDP등으로 통신할 때 클라이언트가 서버에게 보내기 전에 암호화 하고 서버에서 복호화 하고 하는 과정.

• 원래는 이런것을 개발자가 직접 다 해야 하지만 어려우니 openssl이라는 라이브러리를 활용해서 함

• 커스텀 프로토콜을 만들 때는 openssl을 이용해서 개발을 해야 함

TLS 역사

• 1995년 넷스케이프에서 SSL 개발. SSL 1.0, SSL 2.0, SSL 3.0

• SSL 3.0을 보완하여 TLS 1.0 탄생(1999), 현재 버전은 TLS 1.3 (2018)

• 두 개의 주요 프로토콜로 구성
• 레코드 프로토콜(대칭 키가 공유되어 있다는 가정하에 어떻게 암호화 할지를 결정하는 프로토콜)
• 전송할 자료의 형식을 결정
• 암호화가 이루어짐
• 자료는 TLS 레코드 형태로 전송. 레코드는 패킷의 이름
• 핸드세이크 프로토콜
• 자료를 전송하는 방법
• 이 방법이 바로 키 교환/합의 프로토콜임

• TLS는 자신이 전송하는 자료의 의미는 신경쓰지 않음

• 통신 프로토콜 / 응용 프로그램과는 독립적임(어떠한 프로토콜을 쓰던 TLS를 통해 암호화가 가능함. 상관안함)

핸드쉐이크

• TCP 핸드쉐이크(파란색 부분) + TLS 핸드쉐이크(노란색 부분). http 같은 경우는 밑의 노란색 부분이 없음

SSL 인증서 Self-sign시 발생하는 오류

• 이렇게 뜨는 건 서버에서 만든 인증서(Self-sign 하면)가 공공기관의 인증서가 아닌, 우리가 직접 만든 인증서기에 웹브라우저에서 가지고 있는 인증서로는 검증이 안되기 때문에 발생하는 경고임

keytool 을 이용한 루트 인증서 조회, 루트 인증서 추가

keytool -keystore "JAVA Home 경로의 /jre/lib/security/cacerts"  
		-storepass changeit -list -v

keytool -import -keystore cacerts -file "루트인증서파일명" 
		-alias "루트인증서구분용이름"

결론

• ssl 인증서는 다름 아닌 인증 기관이 인정(서명)한 공개 키이다.

• 각 운영체제와 웹브라우저는 유명한 CA의 인증서(공개 키)를 미리 가지고 있어서 서버가 보내 온 인증서를 검증 할 수 있다. 서버의 공개 키를 믿을 수 있음

• TLS는 SSL 3.0을 이어받아 TLS v1, 1.1 1.2 1.3으로 발전 되어 왔고, 레코드 프로토콜과 핸드세이크 프로토콜로 이루어져 있음