HTTP의 문제점
- HTTP(80)는 평문 통신이기 때문에 도청이 가능하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 완전성을 증명할 수 없어 변조가 가능하다.
** 암호화하지 않는 프로토콜의 공통되는 문제점이기도 함.
TCP/IP는 도청 가능한 네트워크이다.
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.
이를 보완하기 위해
- SSL/TLS를 활용하여 통신 내용 자체를 암호화할 수 있다. 또한, SSL을 조합한 HTTP를 HTTPS(HTTP Secure) 혹은 HTTP over SSL이라고 부른다.
- HTTP 메세지에 포함되는 콘텐츠를 암호화한다. 암호화해서 전송하면 받는 측에서 그 암호를 해독하여 출력하는 처리가 필요하다.
통신 상대를 확인하지 않기 때문에 위장이 가능하다.
HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 요청을 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 요청이 오면 상대가 누구든지 응답을 반환한다. 이러한 특징은 여러 문제점을 유발한다.
1. 요청 보낸 곳의 웹 서버가 원래 의도한 응답을 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 응답을 반환한 곳의 클라이언트가 원래 의도한 요청을 보낸 클라이언트인지를 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디에서 누가 요청했는지 확인 불가
4. 의미없는 요청도 수신한다 -> DoS 공격 방지할 수 없다.이를 보완하기 위해
위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.
완전성을 증명할 수 없어 변조가 가능하다.
여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.
이를 보완하기 위해
MD5, SHA-1 등의 해시값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL 에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.
HTTPS
HTTP Secure의 약어로, HTTP에 암호화와 인증, 그리고 완전성 보호를 더했다.
- HTTPS(443)는 SSL의 껍질을 덮어쓴 HTTP로, 새로운 계층의 프로토콜이 아닌 HTTP로 통신하는 소켓을 SSL/TLS로 대체한 것이다.
- HTTP - TCP 통신이 SSL - TCP로 바뀌게 됨
- HTTPS는 암호와, 증명서, 안전성 보호를 이용할 수 있음
- 대칭키 암호화, 공개키 암호화, 하이브리드 암호화 시스템 모두 사용함!!
🔐 대칭키 암호화
- 클라이언트오아 서버가 동일한 키를 이용해 암복호화를 진행함
- 키가 노출되면 매우 위험하나 연산속도 빠름
🔐 공개키 암호화
- 1개의 쌍으로 구성된 공개키와 개인키를 암복호화에 사용함
- 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
동작과정
HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻고 있다.
HTTPS 연결 과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다. 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.
문제는 이 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐 인데, 이 과정에서 비대칭키가 사용된다.
📍 즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.
[인증서를 통한 https 구현 과정은 다음 페이지 참고하기 ]
https://mangkyu.tistory.com/98
🙄 모든 웹 페이지에서 HTTPS를 사용해도 될까?
평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.
