3.버전별 특징
3.1. SSLv1/2/3
+ 넷스케이프에서 개발한 버전으로 1.0버전은 만들어졌으나 치명적인 보안 결함 때문에 공개된 적은 없다.
+ 2.0 버전은 1995년도에 공개되었으나 보안 취약점이 발견되어 다음 해인 1996년 3.0 버전으로 대체되었다.
+ 2016년 현재는 볼 일이 없는 프로토콜인데, 2.0버전은 2011년에 사용이 금지되었으며, 3.0버전도 지원이 끝났다.
+ 두 버전 모두 POODLE, DROWN 등의 추약점이 발견되어 암호화 프로토콜의 기능을 잃은 상태이기 때문이다. 하지만 Internet Explorer 6이 SSL 3.0 프로토콜까지만 지원하는 관계로 아직도 네이버 등 포털 사이트 등에서는 지원하고 있다.
3.2. TLS 1.0
+ 1999년도 SSL 3.0의 업그레이드 버전으로 공개되었다.
+ SSL 3.0과 큰 차이가 있는 것은 아니나, SSL3.0이 가지고 있는 대부분의 취약점이 해결되었다.
+ 후에 등장하는 1.1, 1.2에 비해 장점은 없으나 Internet Explorer 8이 지원하는 가장 높은 TLS 버전인 관계로 아직도 널리 사용되고 있다.
3.2. TLS 1.1
2006년 4월에 공개되었다. 암호 블록 체인 공격에 대한 방어와 IANA 등록 파라메터의 지원이 추가되었다.
3.3. TLS 1.2
2008년도 8월에 공개된 TLS의 최신 버전, 취약한 SHA1 해싱 알고리즘이 SHA256으로 교체되었다.
4.HTTPS
TLS를 사용해 암호화된 연결을 하는 HTTP를 HTTPS라고 하며, 당연히 웹사이트 주소 역시 HTTP가 아닌 HTTPS로 시작된다. 기본 포트는 443번을 쓴다.
흔히 TLS와 HTTPS를 혼동하는 경우가 많은데, 둘은 유사하긴 하지만 엄연히 다른 개념임을 알아두자, TLS는 다양한 종류의 보안 통신을 하기 위한 프로토콜이며, HTTPS는 TLS 위에 HTTP 프로콜을 얹어 보안된 HTTP 통신을 하는 프로토콜이다. 다시 말해 TLS는 HTTP 뿐만 아니라 FTP, SMTP와 같은 여타 프로토콜까지 포함하며, HTTPS 는 TLS 와 HTTP가 조합된 프로토콜만을 가리킨다.
5.문제점
다시 한 번 말하지만, TLS에서 서버 및 클라이언트의 신원을 확인하는 데는 인증서가 사용되며, 인증서의 신뢰성은 인증서를 발급해 준 인증 기관에 의해 결정된다. 인증 기관이 신뢰 가능한 인증서만을 발급해 줬다면 문제가 없지만, 만약 제대로 확인되지 않은 인증서를 발급한다면 더 이상 그 인증서를 신뢰할 수 가 없을 것이다. 그런데 그것이 실제로 일어났다.
몇몇 인증기관에서 보안 수준이 매우 낮은 Domain Validation 인증서를 발급하기 시작한 것이다. 이러한 인증서는 오직 발급을 요청한자가 그 도메인의 소유자가 맞는지만을 인중하기 때문에 사실상 발급 비용만 내면 아무나 인증서를 받을 수 있다. 심지어 해커가 핏ㅇ용 도메인을 만든뒤 인증 기관에 Domain Validation 인증서를 요청하면 그대로 발급된다. 도메인을 소유한 자와 인증서를 신청한 자가 동일한 사람(=해커)이기 때문. 하지만 이 피싱 사이트에 접속한 대부분의 사용자들은 HTTPS 연결이 되었기 때문에 보안이 지켜질 것이라 생각하며 속게 된다.
이러한 문제를 해결하기 위해 나온 것이 EV-SSL 이다. EV-SSL은 공신력 있는 인증 기관에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 보안을 강화한 프로토콜이다. 주요 웹브라우저를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 알려 준다. 인증 조건이 상당히 빡빡해지며 발급 비용이 십수배는 비싸진다는 거은 당연한 수순.
이 외에도 TLS는 망연결에서의 보안을 책임지고 있으므로, 연결된 단말기가 해킹당한 경우라면 아무리 SSL을 써도 무용지물이다. 즉 연결망의 안전성과 노드의 안전성은 별개라는 의미이다.
또한 위 과정을 보면 알겠지만 서버나 클라이언트나 평문 통신에 비해 부하가 크다. 암호화 과정을 거쳐야 하기 때문. 따라서 소규모의 웹사이트에서는 별다른 걱정 없이 HTTPS 프로토콜을 사용하지만 대규모 웹 사이트에서는 쉽게 HTTPS 프로토콜을 적용하지 못하는 경우가 많다. 이를 이용해 프론트엔드 웹을 대상으로 DDoS라도 시도할 경우 암호화 과정 때문에 HTTPS를 사용하지 않은 웹 사이트보다 더 빨리 서버가 죽을 수도 있다. 따라서 웹 사이트 전체에 HTTPS 프로토콜을 적용하기 위해 프론트 서버를 늘리거니 CloudFlare 등의 서비스를 이용하는 경우가 많다.
