이 문제점들은 암호화하지 않은 다른 프로토콜에서도 공통적으로 발생하는 문제점이다.
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로도 도청을 할 수 있다. 평문으로 통신하는 경우 메세지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.
HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리 과정이 존재하지 않는다. 이 때문에 누구든지 요청을 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 접근 제한이 없는 경우(인바운드 규칙이 없는 경우) 요청이 오면 상대가 누구든지 무언가의 응답을 반환하게 된다. 이러한 특징은 다음과 같은 문제를 야기한다.
SSL을 적용하면 상대를 확인할 수 있게 된다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3의 기관에서 발해되기 때문에 서버나 클라이언트가 실재하는 사실을 증명해준다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 또한 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에도 이용할 수 있다.
완전성을 증명할 수 없기 때문에 변조가 가능하다. 여기서 완전성이란 정보의 정확성을 의미한다. 서버나 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수 없는 것이다. 요청이나 응답이 발신된 후 상대가 수신하는 사이에 누군가에 의해 변조되어도 그 사실을 알 수 없다. 이와 같이 공격자가 도중에 요청이나 응답을 변조하는 공격을 중간자 공격 (Man in the Middle)이라고 한다.
MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 방지하기 위해서는 HTTPS를 사용해야 한다. SSL에서는 인증, 암호화, 다이제스트 기능을 제공한다.
HTTPS는 HTTP에 암호화와 인증, 안전성 보호를 더한 프로토콜이다. SSL의 껍질을 덮어 쓴 HTTP라고도 할 수 있다. HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라 HTTP 통신하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체하는 것이다. HTTP는 원래 TCP와 통신한다. 그러나 HTTPS는 SSL과 통신하고, SSL이 TCP와 통신하게 된다. SSL을 이용한 HTTPS는 암호화와 증명서, 안전성 보호를 제공받게 된다.
HTTPS의 SSL은 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 후에 그 이후부터는 공통키 암호를 통신에 사용하게 된다.
HTTPS는 매우 유용한 프로토콜임이 분명하다. 그렇다면 모든 웹 서버에 HTTPS를 적용하는 것이 옳은 것인지 생각해볼 필요가 있다. 우선 답은 "그렇다." 이다.
평문 통신에 비해 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구하게 된다. 통신할 때마다 암호화 작업을 추가적으로 처리해야 하기 때문에 추가적인 리소스가 소비된다. 이에 따라 서버 한 대당 처리할 수 있는 요청의 수가 상대적으로 줄어들게 된다.
그러나 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않고, 새로운 표준인 HTTP 2.0을 함께 이용할 경우 오히려 HTTPS가 HTTP보다 빠르게 동작한다. 따라서 과거에는 민감한 정보를 다룰 때만 HTTPS를 적용했다면 현재는 모든 웹 페이지에 HTTPS를 적용하는 방향으로 흘러가고 있다.