디지털 인증서를 제공하는 공인된 기업들 (Certificate Authority혹은Root Certificate라 부름)
당연하게도 아무 기업이나 할 수 있는 것은 아니고,신뢰성이 엄격하게 공인 된 기업들 만이 참여가 가능하다.
SSL의 암호화
SSL은 보안과 성능 상의 이유로 두가지 암호화 기법을 혼용해서 사용하고 있는데, 우선 이 두가지 암호화 기법에 대해서 정리해보았다.
대칭키
암호화와 복호화에 사용되는 키가 같다
만약에, 정보 송 수신이 이루어 진다면, 정보 전송시에 암호화 키도 같이 전송하여야한다.
이 과정에서, 키가 유출되면, 암호화 된 내용을 공격자가 복호화 할 수 있기 때문에 위험하다
이를 보완하기 위해 나온 방법이공개키 암호화 방식이다.
공개키
암호화와 복호화에 서로 다른 키를 사용한다.
두개의 키를 가지고 있다 (A키, B키)
A키로 암호화하면 B키로 복호화가 가능하고, B키로 암호화하면 A키로 복호화를 할 수 있도록 하는 방식
이 방식에 착안해서 두개의 키 중 하나를 비밀키(private key)로 지정, 나머지를 공개키(public key)로 지정한다.
비밀키는 오직 호스트(서버)만이 가지고 있으며, 클라이언트는 공개키를 사용해 메시지를 암호화 하여 전송 한다.
암호화 된 정보는 오직 비밀키를 가지고 있는 호스트(서버)만이 복호화 할 수 있다.
여기서 의문점 반대로 호스트(서버)가 정보를 암호화해서 클라이언트에게 보내는 경우는 없을까 ? 이 경우에 호스트(서버)가 데이터를 비밀키를 통해 암호화해서 클라이언트에게 보낸다면, 이 과정에서 악의적인 공격으로,"노출 된 공개키를 통해 서버에서 보낸 정보를 복호화 할 수 있지 않을까?"라는 부분이다. 그럼에도 굳이 암호화를 해서 보내는 이유는 뭘까? 이러한 방식은디지털 서명에 이용된다.
디지털 서명
디지털 서명을 통해, 누가 메시지를 썼는지, 메시지의 위조, 변조 여부에 대한 증명이 가능하다. SSL 인증서에서 서비스를 보증하는 방법으로 활용 된다.
비밀키를 갖고 있는 호스트가 데이터를 암호화 한 후, 공개키와 함께 암호화 된 데이터를 전송한다. → '혹여나 중간에 유출되지는 않을까 ?' 할 수 있지만, 이는 데이터를 보호하기 위한 목적이 아니다.
클라이언트는 암호화 된 데이터를 공개키를 통해 복호화 할 수 있다.
이는 데이터가 공개키와 쌍을 이루는 비밀키에 의해 암호화 되었다는 것을 의미 한다.
공개키를 통해 데이터의 출처, 데이터를 제공한 사람의 신원이 보장 된다.
SSL 동작
공개키 방식과, 대칭키 방식을 혼합하여 사용한다.
공개키 방식은 알고리즘 계산이 느리고, 컴퓨터 자원이 많이 소모 된다. 서버 트래픽에 따라 비용이 만만치 않을 수도 있게 된다.
클라이언트와 서버간의 안전한 통신을 위해 채널을 수립하는 Handshake 과정에서 공개키를 사용한다.
실제 데이터를 주고 받는 과정에서는 대칭키 방식을 이용한다.
동작 과정
SSL 동작은 크게 세 단계로 이루어 진다.
Handshake(서로 소통 할 채널을 수립하는 과정)
프로토콜 버전 번호 교환
양쪽이 알고 있는 암호화 방식 선택
서로의 신원을 인증
채널을 암호화 하기 위한 임시 세션 키 생성
데이터 전송
세션 종료
좀 더 과정을 상세히 들여다 보자면,
클라이언트에서 서버로 데이터 전송
클라이언트는 랜덤 데이터를 생성하여 전달한다.
사용 가능한 암호화 방식의 후보들
서버에서 클라이언트로 데이터 전송
서버가 생성한 랜덤 데이터를 전달한다
서버가 선택한 클라이언트의 암호화 방식
인증서 (CA로 부터 발급)
클라이언트는 인증서를 검증한다.
인증서가 CA에 의해서 발급 된 것인지 검사 한다.
서로 주고 받은 랜덤 데이터를 조합해서,pre master secret key(이후에 대칭키로 사용된다)를 생성,인증서에 담겨있는 공개 키를 통해 암호화 하여 전송
서버는 pre master secret key를 복호화
서버가 가지고 있는 비밀키를 통해pre master secret key를 복호화 한다.
이로써 클라이언트 - 서버 둘 다pre master secret key를 공유하게 된다.
서버와 클라이언트 모두 일련의 과정을 거쳐 pre master secret key를 master secret 값으로 생성
master secret를 통해session key를 생성
클라이언트 - 서버 둘 다 동일한session key를 가지게 된다
서버-클라이언트 모두session key를 통해 주고 받는 데이터를 암호화 하여 주고 받을 수 있게 된다. (대칭키 방식)
세션
실제로 서버와 클라이언트가 데이터를 주고 받는 단계
session key값을 이용하여 데이터를 암호화 하여 주고 받는다. (대칭키 방식)
세션 종료
데이터 전송이 끝나면 서로에게 SSL 통신이 끝났음을 알린다 .
통신에서 사용한 대칭키인session key를 폐기한다.
세션의 수립과 세션의 종료는 순식간의 이루어지기 때문에 중간에 대칭키가 유출되더라도, 이미 폐지되어 안전하다고 한다. 물론 100% 안전을 장담 할 수는 없을 것이다.
HTTPS
HTTP + Secure(보안 기능) : HTTP 프로토콜 내용을 암호화
Hyper Text Transfer Protocol Secure Socket layer 의 약자로, HTTP over SSL(TLS), HTTP over Secure라고 부르기도 함
내가 접속한 서버가 의도된 서버임을 보장하며 암호화된 채널을 제공 *암호화된 채널: 무결성과 기밀성을 지켜줌무결성과 기밀성
무결성(integrity) : 메시지가 조작되지 않음 *메시지가 원본 그대로 잘 도착함을 의미
기밀성(privacy) : 메시지를 가로챌 수 없음 *메시지를 읽을수 없다. 즉, 암호화되어 있다를 의미
1. 개념
HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해 HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법 *중간에 인터넷 요청이 탈취되더라도 그 내용을 알아볼 수 없음
SSL(Secure Socket Layer): 보안 소켓 레이어로 Netscape에서 서버와 브라우저 간 보안을 위해 만든 프로토콜 *HTTP 요청과 응답 데이터의 암호화가 이루어지며, 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장
TLS : SSL이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀜 *가장 최신 기술로 더 강력한 버전의 SSL을 의미하지만 SSL이 더 일반적으로 사용되는 용어
HTTP보다 상대적으로 안전한 방법이고, 데이터 제공자의 신원을 보장받을 수 있기 때문에 인증에서 HTTPS 프로토콜을 사용해야 함
데이터 제공자의 신원을 확인하고 보장받는 게 인증에서 중요한 이유
클라이언트는 데이터 제공자가 제공해준 데이터를 사용할 수밖에 없음
클라이언트는 서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면을 렌더링하는 등의 작업을 수행
위의 이유로 클라이언트는 요청 및 응답을 중간에서 가로채는 중간자 공격에 취약
중간자 공격 : 클라이언트와 서버 사이에서 공격자가 서로의 요청, 응답의 데이터를 탈취 및 변조하여 다시 전송하는 공격
중간자 공격 시 데이터가 중간에 다른 도메인을 거쳐서 전달되기 때문에 서버가 해당 데이터가 제공된 도메인에 대한 추가데이터를 응답객체에 실어 보냄
중간자 공격으로 인해 다른 도메인에서 데이터를 받은 클라이언트는 데이터를 제공한 도메인과 전달받은 내용의 도메인을 비교하여 중간자 공격이 존재하는지 아닌지 확인할 수 있음
중간자 공격으로 인한 추가 데이터 또한 변조할 수 있기 때문에 해당 데이터를 암호화시키는 작업이 필요
2. 특징
1) 인증서(Certificate)
인증서 : 브라우저와 서버가 통신할 때 암호화할 수 있도록 서버의 공개 키 제공 *참고자료
데이터 제공자 신원 보장 : 데이터를 제공한 서버가 정말로 데이터를 보내준 서버인지 인증 및 확인 *https://google.com: 내가 접속한 사이트가 진짜 google임을 보장
도메인 종속 : 인증서의 내용에 서버의 도메인 관련 정보가 있어 데이터 제공자의 인증을 용이하게 함
브라우저는 응답과 함께 전달된 인증서 정보를 확인할 수 있음 *인증서의 도메인 정보와 데이터 제공자의 도메인 정보가 다른 중간자 공격을 감지하여 보안 위협으로부터 사용자 및 사용자의 데이터를 보호
중간자 공격 인지 시 경고를 보여줌으로써 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용할 수 있게 사용자를 유도
인증 과정
요청을 받으면 서버는 인증서와 함께 요청의 응답을 전송
응답을 받은 클라이언트는 인증서에 작성된 도메인과 응답 객체에 작성된 도메인을 비교
응답에서 확인한 도메인과 인증서에 작성된 도메인이 같다면 데이터를 보내준 서버가 확실하다는 것을 인지
중간자가 요청을 탈취해 서버인척, 클라이언트인척 정보를 탈취한 경우, 응답에서 확인한 도메인과 인증서에 작성된 도메인이 같지 않아 데이터를 보내준 서버가 맞는지 확신할 수 없게 됨
2) CA(Certificate Authority)
인증서를 발급하는 공인된 기관
각 브라우저는 각자 신뢰하는 CA의 정보를 가지고 있음 *각 브라우저마다 인증서에 차이가 있음
CA의 자격은 계속 유지되는 것이 아니라, 자격을 박탈당할 수 도 있음
CA로부터 발급받은 인증서 : 공개 키는 브라우저에, 개인 키는 서버에 저장 *CA는 몇군데 안되므로 리스트가 저장되어 있음
mkcert로 만든 임의의 인증서 : CA는 내 컴퓨터 *CA 리스트에 없으므로 배포시 invalid 에러 발생
3) 비대칭 키 암호화
암호화 : 복호화가 가능한 알고리즘을 사용
비대칭 키 암호화 : 전혀 다른 키 한 쌍으로 암호화 및 복호화 가능 *대칭 키 암호화 : 암호화와 복호화를 하는 키가 같음
HTTPS 프로토콜을 이용하는 서버는 한 쌍의 키 중에서 하나는 숨겨두고, 다른 하나는 클라이언트에 공개하여 데이터를 안전하게 전송할 수 있게 함 *일반적으로 공개 키는 암호화, 비공개 키(개인 키)는 복호화에 사용
모든 통신에 대해 공개 키 방식을 사용하지는 않음 *공개 키 방식은 많은 클라이언트를 상대로 매번 사용하기에는 연산이 매우 복잡
통신의 초창기에서만 비밀 키 생성을 목적으로 공개 키 방식 사용
통신 과정
Hand Shake
서로를 확인 후 서버는 클라이언트에게 한쌍의 키중 하나를 공개 키로 전달
비밀 키 생성
클라이언트는 전달받은 키를 이용하여 서버와 키를 만들어낼 임의의 정보를 암호화하여 전송
서버도 클라이언트와 마찬가지로 임의의 정보를 암호화하여 전송
서로 만들고 교환한 임의의 정보를 바탕으로 비밀 키를 생성
상호 키 검증
각자 생성한 키를 바탕으로 클라이언트가 테스트용 데이터를 만들어낸 비밀키로 암호화하여 전달
