주제: SSL, TLS, HTTPS에 대해 조사하고 발표하기

• (옵션) TCP/IP 계층모델을 설명하고 WireShark를 활용해 실제 HTTP 데이터가 패킷상에 어떻게 존재하는지 시연 → 시연하면서 encapsulate + decapsulate 과정 설명
• (옵션) OSI 계층 모델을 설명하고 이 모델을 준수하는 use case설명 및 발표 (조사하기 힘듭니다. 최후순위로 두세요!)

나만의 언어로 정리

HTTPS

• HTTP에 보안을 더한 프로토콜
• 기존 HTTP는 암호화 되지 않은 방법으로 데이터를 전송하므로 감청당하는 등 보안에 취약하다는 단점이 있었음. 이 점을 보완하기 위해 나온 것이 HTTPS.
• OSI 7계층에서 Application 계층에 속하며, SSL/TLS 위에서 동작함.

SSL/TLS

• 클라이언트와 서버간에 데이터를 암호화해 안전하게 통신하게 도와주는 보안 계층
• SSL 3.0 이후부터는 TLS이라 부름. SSL과 TLS는 정확히 말하자면 다르지만, 이미 SSL이라는 이름이 익숙해져서 TLS과 같은 의미로 쓰임. (현재 SSL(3.0 이전)은 사용하지 않음)
• 대칭키와 공개키 기법 두가지 함께 사용.

대칭키와 공개키

• 대칭키: 같은 키로 암호화와 복호화 둘 다 가능. 따라서 절대로 노출되어서는 안된다. 보안에 취약하지만 공개키보다 빠른 속도.
• 공개키: 서로 다른 두 키가 한 쌍으로 작동. 서로 다른 두 키의 종류로는 공개키와 개인키가 있다. 공개키는 누구에게나 공개되는 키로 클라이언트가 소유하고 있다. 개인키는 서버만이 가지고 있는 키. 공개키로 암호화했다면, 오직 개인키로만 복호화가 가능하다. 개인키로 암호화했다면, 오직 대칭키로만 복호화가 가능하다.

SSL의 동작 과정

1. Client Hello
   랜덤한 데이터와 C에서 현재 지원하는 암호화 방식 목록을 전달한다. 암호화 방식을 전달하는 이유는 어떤 기법으로 암호화 할 지를 협의하기 위함이다.
   
2. Server Hello
   랜덤한 데이터, C가 보낸 목록 중 S에서 현재 지원하는 암호화 방식 목록, 인증서를 전달한다. 여기서 인증서란? 이 서버가 신뢰할 수 있음을 보장하는 문서로 품질보증서와 같은 개념이다. 이 인증서는 CA라는 공식 인증된 기관에서 발급해준다.
   
3. 인증서 검증
   클라이언트는 서버로부터 받은 인증서가 진짜인지, 믿을만한지 한 번 더 검증한다. 우선, CA가 발급한 인증서 목록 중에서 서버가 전달한 인증서가 있는지 확인한다. 만약 인증서가 목록에 있다면, 한번 더 철저히 확인하기 위해 검증을 거친다. 목록에서 찾은 인증서의 공개키(CA에서 공유하는)를 가지고 서버에서 보내준 인증서를 복호화한다. 만약 복호화에 성공한다면, 이 인증서가 진짜라는 뜻으로 클라이언트는 서버를 온전히 신뢰할 수 있게 된다. (서버가 자신의 비밀키로 암호화 했음이 인증되므로)
   
4. 임시 키 생성
   이제 서버도 검증했겠다 본격적으로 통신을 시작하기 전, 클라이언트에서 임시 키를 생성한다. 이때 생성한 임시키는 대칭키로, 절대로 외부에 노출되어서는 안된다.(대칭키는 키 하나로 복호화,암호화가 가능하므로 노출되는 순간 보안이 깨짐.) 이 임시 대칭키의 보안을 지키기 위해 인증서의 공개키로 이 임시키를 암호화한다. 공개키로 암호화한 임시대칭키를 서버에 전달한다. 만약 이 임시대칭키가 중간에 노출된다 하더라도 이를 복호화시킬 수 있는 것은 오직 개인키이므로 서버 외에는 복호화 할 수 없다.
   
5. 클라이언트로부터 대칭키를 전달받음
   서버는 공개키로 암호화된 임시 대칭키를 받게 된다. 암호화된 임시키를 서버의 개인키로 복호화하면 원래의 임시 대칭키를 얻을 수 있다. 이로써 클라이언트와 서버 모두 같은 대칭키를 외부로 노출시키지 않고 안전하게 소유하게 된다.
   
6. 본격적으로 통신할 준비
   서버와 클라이언트의 대칭키는 일련의 과정을 거쳐 세션 키로 바뀌게 되고, 이 세션 키를 이용해 클라이언트와 서버는 통신할 수 있게 된다. 이후, 앞서 생성한 세션키를 이용해 데이터를 암호화해 통신하게 된다.