HTTP의 약점

1 ) 평문 통신이기 때문에 도청이 가능

HTTP를 사용한 리퀘스트나 리스폰스 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화 되지 않음
-> TCP/IP의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있음

인터넷은 전 세계를 경유하는 네트워크로 되어 있는데, 어느 서버와 클라이언트가 통신을 할 때, 통신 경로 상에 있는 네트워키 기기나 케이블이나 컴퓨터 등을 전부 자기 자신이 소유하고 있는 일은 있을 수 없음
-> 즉 악의를 가지면 엿볼수 있음(암호화 하더라도 암호화된 메세지 자체는 볼 수 있음)
-> ex) 패킷을 탈취하는 경우

도청을 피하기 위한 암호화에는 통신 암호화와 콘텐츠 암호화가 있음

통신 암호화

HTTP에는 암호화 구조가 없지만 SSL(Secure Socket Layer)나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용 암호화 가능
-> SSL 등을 이용해 통신로를 확립하고 난 후 통신로를 사용해 HTTP 통신 진행

SSL이란 클라이언트(예: 웹 브라우저)와 서버(예: 웹 사이트) 사이에 암호화된 링크를 설정하여 인터넷을 통해 보안 통신을 제공하는 프로토콜
-> SSL/TLS는 인터넷 통신을 위한 중요한 보안 계층을 제공하고 민감한 정보가 가로채는 것을 방지하는 데 도움

콘텐츠 암호화

HTTP 메세지에 포함되는 콘텐츠만 암호화하는 방법
-> 이 경우 클라이언트에서 HTTP 메세지를 암호화해서 출력하는 처리가 필요하게 됨

2) 통신 상대를 확인하지 않기 때문에 위장 가능

HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않음
-> 리퀘스트를 보낸 서버가 정말로 URI에서 지정된 호스트 인지 아닌지, 리스폰스를 반환한 클라이언트가 정말로 리퀘스트를 출력한 클라이언트인지 아닌지를 모른다는 것!

HTTP는 누구이던 간에 리퀘스트를 보내면 리스폰스가 반한되는 매우 심플한 구조(상대방 확인 X, 약점을 가지게 됨)
-> 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 아닌지를 확인할 수 없음(위장한 웹서버 일수도 있다)
-> 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트 인지 아닌지 확인 불가
-> 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인 불가
-> 어디의 누가 리퀘스트를 했는지를 확인할 수 없고, 의미 없는 리퀘스트라도 수신하게 됨(Dos 공격 방지 불가)

상대를 확인하는 증명서

HTTP 에서는 통신 상대를 확인할 수 없지만, SSL로 상대를 확인할 수 있음
-> SSL은 암호화 뿐만 아니라, 상대를 확인하는 수단으로 증명서를 제공

증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이기에 서버나 클라이언트가 실재하는 사실을 증명
-> 클라이언트는 통신을 개시할 때에 서버의 증명서를 확인

3) 완전성을 증명할 수 없기 때문에 변조 가능

완전성 == 정보의 정확성을 가리킴

HTTP가 완전성을 증명할 수 없다는 뜻은 만약 리퀘스트나 리스폰스가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었다고 하더라도 이 사실을 알수 없다는 뜻
-> 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-In-the-Middle 공격)이라고 부름

변조를 방지하기 위해 보통 MD5나 SHA-1 등의 해시 값을 확인하거나, 디지털 서명을 확인 함
-> 이 또한 확실히 확인하기는 힘들어 HTTPS를 사용할 필요가 있음
-> SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공
-> HTTP 만으로는 완전성을 보증하기 어려워 다른 프로토콜을 조합함

---

HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS

앞서 설명한 것처럼 HTTP 통신은 암호화 되지 않은 평문으로 실시되며, 통신 상대의 서버나 클라이언트를 인증하는 수단이 없음(의도하지 않은 상대와 통신할 가능성)
-> 메세지가 도중에 변조되어 있을 가능성도 존재

HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니며, HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)나 TLS(Transport Layer Security)라는 프로토콜로 대체하고 있음

보통 HTTP는 직접 TCP와 통신하지만, SSL을 사용한 경우에는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신

공개키 암호화 방식

SSL에서는 공개키 암호화 방식이라 불리는 암호화 방식을 채용

암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 함
-> 즉 키를 손에 넣으면 누구라도 암호를 해독이 가능함

공통키 암호화 방식은 상대방에게 키를 넘겨주어야 함!
-> 만약 네트워크를 사용해서 키를 넘겨줄 때 통신이 도청되어 공격자에게 키를 뺴앗기게 되면 암호화의 의미가 없게 되버림
-> 이를 해결하려고 한 것이 공개키 암호라는 방식

공개키 암호에서는 서로 다른 두개의 키 쌍(공개키+비밀키)을 사용

공개키 방식에서는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 하고, 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 진행
-> 이는 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해 키를 빼앗길 걱정 X

HTTP는 공통키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템
-> 공개키 암호는 안전하지만 공통키 암호에 비해 처리 속도가 느림

두 가지 장점을 살릴 수 있도록 각각의 방식을 조합해서 통신
-> 공통키 암호로 사용하는 키를 교환하는 곳에서는 공개키 암호를 사용하여 안전하게 교환하고 그 후의 통신에서 메세지를 교환하는 곳에서는 공통키 암호를 사용

공개키를 증명하는 증명서(인증 기관)

공개키 방식 사용시에는 공개키가 진짜인지 아닌지를 증명할 수 없음
->ex) 어떤 서버와 공개키 암호를 사용해서 통신을 하려할 때 수신한 공개키가 본래 의도한 서버가 발행한 공개키인지 증명하기 힘듬(공격자가 공개키를 바꿔치기 했을수도)
-> 이러한 문제를 해결하기 위해 인증기관(CA)과 그 기관이 발행하는 공개키 증명서가 이용됨

인증기관을 이용한 공개키 이용 절차

1. 서버의 공개키를 인증 기관에 등록
2. 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 증명서를 작성 등록(이때 인증기관의 공개키는 사전에 브라우저에 내장되어 있음)
3. 클라이언트는 서버의 공개키 증명서(서버의 공개키 + 인증기관 디지털 서명)를 입수하고, 디지털 서명을 인증 기관의 공개 키로 검증한 후, 공개키가 진짜인지 확인
4. 서버의 공개키로 암호화해서 메세지를 송신 기관에 등록
5. 서버의 비밀키로 메세지를 복호화

클라이언트 증명서

HTTPS에서는 클라이언트 증명서도 이용 가능
-> 클라이언트 증명서를 이용하여 서버 증명서와 같이 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 인증 진행 가능
-> 유저가 직접 증명서를 유료로 구입해서 인스톨 해야한다는 단점 존재

---

HTTPS 통신 구조

HTTPS로 통신하기 위해서는 클라이언트-서버가 handshake 과정으로 통신을 진행

1. 클라이언트가 Client Hello 메세지를 송신하면서 SSL 통신을 시작
   -> 메세지에는 클라이언트가 제공하는 SSL의 버전을 지정하고, Cipher Suite로 불리는 리스트 등이 포함되어 있음

2. 서버가 SSL 통신이 가능한 경우에는 Server Hello 메세지로 응답

3. 서버가 Certificate 메세지를 송신(메세지에 공개키 증명서가 포함되어 있음)

4. 서버가 Server Hello Done 메세지를 송신하여 최초의 SSL 네고시에이션 부분이 끝났음을 통지

5. SSL의 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange 메세지로 응답(이 메세지는 3의 공개키 증명서에서 꺼낸 공개키로 암호화 되어 있음)

6. 클라이언트는 Change Cipher Spec 메세지를 송신(이 메세지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타내고 있음)

7. 클라이언트는 Finished 메세지 송신, 이는 접속 전체의 체크 값을 포함하고 있음
   -> 네고시에이션이 성공했는지 어떤지는 서버가 이 메세지를 올바르게 복호화할 수 있는지 아닌지가 결정

8. 서버에서 Change Cipher Spec 메세지 송신

9. 서버에서 Finished 메세지 송신

10. 서버와 클라이언트의 Finished 메세지 교환이 완료되면 SSL에 의해서 접속은 확립됨
    -> 이후 부터는 애플리케이션 계층의 프로토콜에 의해 통신(즉 HTTP Request 송신)

11. HTTP 리스폰스 송신

12. 마지막에 클라이언트가 close_notify 메세지를 송신하면서 접속을 끊음

HTTP와 같은 평문 통신에 비해 HTTPS와 같은 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요함
-> 즉 한대당 처리할 수 있는 리퀘스트의 수가 줄어들게 되므로 민감한 정보가 포함되지 않는 통신에서는 HTTP를 사용함