웹을 안전하게 지켜주는 HTTPS
🎈<목차>
1. HTTP의 약점
2. 이를 해결하기 위한 HTTPS 등장
3. SSL과 TLS
🎆 1. HTTP의 약점
평문(암호화 하지 않은)통신이기 때문에 도청가능
통신 상대를 확인하지 않기 떼문에 위장 가능
완전성을 증명할 수 없기 때문에 변조 가능
1.1 평문(암호화 하지 않은)통신이기 때문에 도청가능
HTTP를 사용한 리퀘스트나 리스폰스 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않는다. 즉, 평문(암호화 되지 않는 메시지)으로 HTTP 메세지를 보내게 된다.
TCP/IP는 도청이 가능한 네트워크
TCP/IP의 구조의 통신은 전부 통신 경로의 도중에 엿볼 수 있다. 통신 내용을 엿 볼 수 있다는것은, 암호화된 통신에서도 암호화되지 않는 통신도 같다. 암호화 통신은 메세지 속의 의미는 간파 할 수 없을 수도 있지만 암호화된 메시지 자체는 엿볼수 있다.
같은 세그먼트의 통신을 도청하는 것은 그리 어려운것이 아니며, 네트워크 상을 흐르고 있는 패킷을 수집하는것만으로 도청할 수 있게 된다. 패킷을 수집하려면 패킷을 해석하는 패킷 캡쳐나 스니퍼라는 툴을 사용한다.
위의 화면은 자주 사용되고 있는 패킷 캡처인 [wireshark]라는 툴을 사용해서 HTTP를 사용한 리퀘스트와 리스폰스의 내용을 취취득해서 해석한것이다. GET을 사용해서 리퀘스트를 하고 있는 모습과 그 리스폰으에 "200 OK"를 반환하고 리스폰스의 HTTP메세지 내용이 전부 나타고 있는 것을 알 수 있다.
해결 방법 : 암호화로 도청을 피한다
1) 통신 암호화
통신을 암호화하는 방법은, HTTP에는 암호화 구조가 없지만 SSL(Secure Socket Layer)이나 ,TLS(Transport Layer Security)이라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화 할 수 있다. SSL 등을 이용해 안전한 통신로를 확립하고 나서 그 통신로를 이용해 HTTP 통신을 한다. SSL을 조합한 HTTP를 HTTPS나 HTTP over SSL이라 불리고 있다.
2) 콘텐츠 암호화
다른 한가지는 통신하고 있는 콘텐츠를 암호화하는 방법이다. HTTP에는 암호화 기능이 없기 때문에 HTTP를 사용해서 운반하는 내용을 암호화하는 것이다. 이 경우 클라이언트에서 HTTP 메시지를 암호화해서 출력하는 처리가 필요하게 되는데 물론, 콘텐츠의 암호화를 유효하게 하기 위해서는 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 이쓴것이 전제가 되므로, 평상시에 유저가 사용하는 브라우저와 웹 서버에서 이용하는것은 어려운것이다.(주로 웹서비스에서 이용되는 방법이다.)
1.2 통신 상대를 확인하지 않기 때문에 위장 가능
HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않는다. 리퀘스트를 보낸 서버가 정말로 URI에서 지정된 호스트인지,리스폰스를 반환한 클라이언트가 정말로 리퀘스트를 출력한 클라이언트인지 아닌지를 모른다는 것이다.
즉, 다음과 같은 약점은 아래와 같다.
- 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 아닌지를 확인할 수 없다. 위장한 웹 서버일 우려가 있다.
- 리스폰스를 반환한 곳의 클라인언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 아닌지를 확인할 수 없다. 위장한 클라이언트일 우려가 있다.
- 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수가 없다. 중요한 정보를 가진 웹 서버에서는 특정 상대만 통신을 허가하고 싶을 때가 있다.
- 어디의 누가 리퀘스트를 했는지를 확인할 수 없다.
- 의미없는 리퀘스트라도 수신하게 된다 .대량의 리퀘스트에 의한 DOS공격을 방지할 수 없다.
해결 방법 : 상대를 확인하는 증명서를 가진다.
HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다 SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있다.
증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다.또 그 증명서를 위조하는것은 기술적으로 상당히 어려우며, 통신 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있다.
1.3 완전성을 증명할 수 없기 때문에 변조 가능
HTTP가 완전성을 증명할 수 없다는 뜻은 만약 리퀘스트나 리스폰스가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었다고 하더라도 이 사실을 알 수 없다는 뜻이다. 즉, 발신된 리퀘스트나 리스폰스와 수신한 리퀘스트나 리스폰스가 같은지 아닌지를 확인 할 수 없다는 의미이다.
예를 들어, 어떤 웹사이트에서 콘텐츠를 다운 했다고 하면 클라이언트에 다운로드한 파일과 서버 상에 있는 파일 이 정말로 같은 것인지 아닌지 모른다는 것이다. 콘텐츠가 도중에 다른 내용으로 변경되었을지도 모르며,알아차릴 수 없다.
이와 같은 공격자가 도중에 리퀘스트나 리스폰스를 빼았아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부릅니다.
해결방법 변조를 방지한다.
HTTP를 사용해서 완전성을 확인하기 위한 방법은 있지만, 확실하면서 편리한 방법은 현재로서는 존재하지 않는다. 그중에서도 자주 사용되고 있는 방법은 MD5나 SHA-1등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이다.
하지만 아쉽게도 위의 방법으로 확실히 확인할 수 있는 것은 아니며, 그것은 PGP와 MD5 자체도 적절하게 수정되어 있다고 한다면, 유저로서는 알 수가 없기때문에 확실하게 방지하기에는 HTTPS를 사용할 필요가 있다.SSL에는 인증이난 암호화, 그리고 다이제스트 기능을 제공하고 있고, HTTP만으로는 완정성을 보증하는것이 어렵기 때문에 다른 프로토콜을 조절함으로써 실현해야한다.
🎇2. 이를 해결하기 위한 HTTPS 등장
2.1 HTTPS는 SSL의 껍질을 덮어쓴 HTTP
HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니다. HTTP 통신을 하는 소켓부분을 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)이라는 프로토콜로 대체하고 있을 뿐이다.
보통 HTTP는 직접 TCP와 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL와 통신하고 SSL이 TCP와 통신하게 된다. 즉 SSL이라는 껍질을 덮어쓴 HTTPS인것이다.
SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용할 수 있게 되며, SSL은 HTTP와는 독립된 프로토콜로 HTTP만으로는 애플리케이션 계층에서 동작하는 SMTP나 Telnet 등에서도 이용될 수 있다. SSL은 현재 세계 어는 곳에서도 널리 사용되고 있는 네트워크 보안 기술이라고 말할 수 있다.
2.2 상호간에 키를 교환하는 공개키 암호화 방식
SSL에서는 키 암호화 방식이라 불리는 암호화 방식을 채용하고 있다. 현대의 암호화는 알고리즘이 공개되어 있고 키를 비밀에 부침으로써 안전성을 유지한다. 암호화나 복호화 할 때 이 키를 사용한다.
- 공동키 암호의 딜레마
1)네트워크를 사용해서 키를 넘겨줄 때 통신이 도청될 위험이 있다.
2) 받은 키를 안전하게 보관하기 위한 노력을 하지 않으면 안된다.
해결방안
1). 두 개의 키를 사용하는 공개키 암호
공개키 암호에서는 서로 다른 두 개의 키 페어(쌍)를 사용한다. 한쪽은 비밀키라고 부르고 다른 한쪽은 공개키라고 부른다. 이름대로, 비밀키는 누구에게도 알려지면 안되는 키이며, 공개키는 누구에게나 알려져도 괜찮은 키이다.
공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 한다. 그리고 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시한다. 이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해서 키를 빼앗길 걱정은 없다.
또한 암호문과 공개키라는 정보에서 평문을 구한는 것은 매우 어려운 수학적인 특징이 있기 때문에간단하지는 않으며, 만약 큰 수의 소인수 분해를 고속으로 할 수 있다면 해독할 수 있지만, 현재로써는 쉽지 않다.
2) HTTPS는 하이브리드 암호 시스템
HTTP는 공동키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템이다. 키를 안전하게 교환할 수만 있다면 공개키 암호만을 사용해서 통신을 해도 괜찮다고 생각할 지도 모르지만, 공개키 암호는 공동키 암호에 비해서 처리 속도가 늦는다.
거기서 두가지 장점을 살릴 수 있도록 각각의 방식을 조합해서 통신하며, 키를 교환하는 곳에서는 공개키 암홀르 사용하고 그 후의 통신에서 메세지를 교환하는 곳에서는 공동키 암호를 사용하는것이다.
2.3 공개키가 정확한지 아닌지를 증명하는 증명서
이 문제를 해결하는 데는 인증기관(CA: Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있다. 인증 기관이란 클라이언트와 서버가 모두 신뢰하는 제 3자 기관이다. 유명한 인증 기관에는 VeriSign사가 있다.
인증기관은 다음과 같이 이용된다.
1) 서버의 공개키를 인증 기관에 등록
2) 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 증명서를 작성 등록
3) 서버의 공개키 증명서를 입수하고, 디지털 서명을 인증 기관의 공개 키로 검증하고, 공개키가 진짜인지를 확인
4) 서버의 공개키로 암호화해서 메세지를 송신기관에 등록
5) 서버의 비밀키로 메세지를 복호화
증명서의 종류=> EV SSL 증명서, 클라이언트 증명서, '나야 나 증명서'
2.4 HTTPS의 통신과정
✨ 3. SSL과 TLS
HTTPS에서는 SSL(Secure Socket Layer)과 TLS(Transport Layer Security)라는 두개의 프로토콜이 사용되고 있다. 현재는 SSL3.0,TLS1.0이 주류이며, SSL1.0프로토콜은 설계시점에서 문제가 발견되었기 때문에 실제로 사용되지는 않았으며, SSL2.0이라는 프로토콜에도 문제가 발견되었기 때문에 많은 브라우저에서는 무효화가 되고 있다.
3.1 SSL은 느리다?
SSL 통신이 지연되는 이유에는 2가지가 있다.
하나는 통신속도가 떨어지는 것과 가른 하는 CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려지는 것이다. 네트워크 부하는 HTTP를 사용하는 경우에 비해 2배에서 100배 정도 느려질 수 있다. TCP 접속과 HTTP 리퀘스트/리스폰스 이외에 SSL에 필요한 통신이 추가되기 때문에 전체적으로 처리해할 통신이 증가해 버린다.
다른 하나는 SSL은 반드시 암호화 처리를하고 있기 때문에 서버난 클라이언트에서는 암호화난 복호화를 위한 계산을 할 필요가 있다. 그렇기 때문에 서버난 클라이언트의 리소스를 소비하게 되어 HTTP에 비해 부담이 커진다.
느려지는 것에 대한 근본적인 해결 방법은 없기 때문에 SSL 엑셀레이터라는 하드웨어(appliance 서버)를 사용해서 이 문제를 해결하기도 한다. SSL 엑셀레이터는 SSL을 처리하기 위한 전용 하드웨어로 소프트웨어로 SSL을 처리할 때보다 몇배 빠른 계산을 할 수 있다. SSL의 처리만 SSL 엑셀레이터에 맡김으로써 부하를 분산하도록 하고 있다.
📚 관련 서적
0개의 댓글
