○ SSL 매커니즘

보안과 성능상 이유로 아래 두 가지 기법을 혼용하여 사용

- 대칭키

· 동일한 키로 암호화와 복호화를 같이 하는 방식

· 대칭키 유출 시 암호의 내용을 복호화할 수 있기 때문에 암호를 주고받는 사람들 사이에서 대칭키 전달이 어려움 -> 공개키로 해결

- 공개키

· 두 개의 키로 암호화, 복호화를 하는 방식(A키로 암호화 시 B키로 복호화, 그 역도 성립)

-> 두 개의 키를 각각 비공개키, 공개키로 설정하여 비공개키는 자신만 가지고 있고 타인이 공개키로 암호화한 내용을 비공개키로 복호화

-> 비공개키로 암호화 후 공개키와 함께 암호화된 정보 전송하여 데이터가 공개키와 쌍을 이루는 비공개키로 암호화 된 것을 증명(전자서명)

○ SSL 인증서

- SSL 인증서 기능

· 통신 내용이 공격자에게 노출되는 것을 방지

· 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장

  (CA(Certificate Authority 또는 Root Certificate)라는 기업들에 의해 수행

  ex) Symantec, Comodo 등)

· SSL 통신에 사용할 공개키를 클라이언트에게 제공

- SSL 인증서 내용

· 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)

· 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)

 -> CA는 자신의 비공개키를 이용하여 서버가 제출한 인증서를 암호화

○ SSL의 동작

- 신뢰할 수 있는 서비스 증명: 웹브라우저가 서버에 접속 > 서버가 인증서 제공 > 제공된 인증서의 CA가 브라우저에 내장된 CA리스트내에 있는지 확인 > CA의 공개키를 이용해 인증서 복호화 > 복호화가 되면 인증서가 해당 CA의 비공개키에 의해 암호화된 것이므로 신뢰할 수 있는 서비스인 것이 증명

- 데이터 암호화: 네트워크 통신(악수 → 전송 → 세션종료)시 SSL이 데이터를 암호화함(실제 데이터는 대칭키로, 대칭키의 키는 공개키로 암호화)

· 악수(handshake):

1) 클라이언트가 서버에 접속(Client Hello) 및 주고받는 데이터:

 ☞ 클라이언트 측에서 생성한 랜덤 데이터

 ☞ 클라이언트가 지원하는 암호화 방식(클라이언트와 서버가 지원하는 암호화 방식이 달라, 어떤 암호화 방식을 사용할 것인지 협상 필요)

 ☞ 세션 아이디: 추후 악수 과정을 생략하기 위해 사용자 세션을 서버로 전송

2) 서버 측 응답(Server Hello) 및 주고받는 데이터

 ☞ 서버 측에서 생성한 랜덤 데이터

 ☞ 서버가 선택한 클라이언트 암호화 방식

 ☞ 인증서

3) 클라이언트가 내장된 CA리스트 확인 및 해당 CA의 공개키를 통한 복호화 과정을 거쳐 신뢰할 수 있는 서버인지 확인 > 클라이언트가 클라이언트 랜덤 데이터와 서버 랜덤 데이터를 조합하여 대칭키(pre master secret)를 생성 > 서버로부터 받은 인증서에 들어있는 공개키를 이용해서 pre master secret값을 암호화 후 서버로 전송

4) 서버가 전송받은 pre master secret값을 자신의 비공개키로 복호화(서버와 클라이언트 모두 pre master secret을 공유) > 서버가 pre master secret값을 일련의 과정을 거쳐 master secret값으로 생성 > master secret이 session key를 생성 > session key값을 이용하여 클라이언트와 서버간 데이터를 대칭키 방식으로 암호화하여 전송(서버와 클라이언트 모두 session key를 공유)

5) 클라이언트와 서버가 악수단계 종료를 서로에게 알림

· 세션(정보를 주고 받는 단계): 정보를 상대방에게 전송시 session key값을 이용해 대칭키 방식으로 암호화, 상대방은 해당 대칭키를 통해 복호화

* 공개키 방식이 많은 컴퓨터 파워를 사용하기 때문에 많은 접속이 물리는 서버에 큰 부하를 가져오며, 대칭키 전송시 암호화 되지 않는 인터넷을 통해서 전송하는 것은 위험

-> 속도는 느리지만 데이터를 안전하게 주고받을 수 있는 공개키로 대칭키를 암호화하여 실제 데이터 전송시에는 대칭키를 사용

· 세션종료: 데이터 전송이 끝나면 SSL통신이 끝났음을 서로에게 알리고 session key 폐기



□ HTTP vs HTTPS(Hypertext Transfer Protocol Over Secure Socket Layer)

○ 차이점

HTTP의 보안을 강화한 것이 HTTPS로 SSL프로토콜 위에서 돌아가는 프로토콜임. HTTP는 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트 간의 메시지를 감청당할 위험이 있음.

○ 모든 웹사이트가 HTTPS를 쓰지 않는 이유

- 보안인증 비용, SSL(or TLS) 키 교환 시 호출시간 소요(웹 서버 부하),

- 불특정 다수에게 공개해도 상관없는 페이지는 http로, 메일이나 로그인 등의 페이지는 https로 하는 것이 효율적