[Network] HTTPS

[ HTTP의 약점 ]

• HTTP는 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없기 때문에 변조 가능

 

TCP/IP 는 도청 가능한 네트워크

TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있습니다.

통신 내용을 엿볼 수 있다는 것은, 암호화된 통신에서도 암호화되지 않은 통신에서도 같습니다.

암호화 통신은 메시지 속의 의미는 간파할 수 없을 수도 있겠지만 암호화된 메시지 자체는 엿볼 수 있습니다.

1. 통신 암호화
   • SSL을 조합한 HTTP를 HTTPS(HTTP Secure)나 HTTP over SSL이라 불리고 있습니다.
   • 통신을 암호화 하는 방법입니다. HTTP에는 암호화 구조는 없지만 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)이라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화 할 수 있습니다.
2. 콘텐츠 암호화
   • 이 경우, 클라이언트에서 HTTP 메시지를 암호화해서 출력하는 처리가 필요합니다.
   • 콘텐츠의 암호화를 유효하게 하기 위해서는 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 것이 전제가 되므로, 평상시에 유저가 사용하는 브라우저와 웹 서버에서는 이용하는 것은 어렵습니다.
   • 콘텐츠의 내용 자체를 암호화 하는 방법입니다. HTTP에 암호화를 하는 기능은 없기 때문에 HTTP를 사용해서 운반하는 내용을 암호화하는 것입니다.

 

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

HTTP는 누구이던 간에 리퀘스트를 보내면 리스폰스가 반환되는 매우 심플한 구조로 되어 있지만, 상대를 확인하지 않는 점이 약점일 수가 있습니다.

• 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 아닌지를 확인할 수 없다.
• 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 아닌지를 확인할 수 없다.
• 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다.
• 어디의 누가 리퀘스트를 했는지를 확인할 수 없다.
• 의미없는 리퀘스트라도 수신하게 된다. 대량의 리퀘스트에 의한 Dos 공격(서비스 불능 공격)을 방지할 수가 없다.

 

보안 방법

HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있습니다.

SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있습니다.

증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명합니다.

증명서를 이용함으로써, 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 됩니다.

또한 클라이언트가 증명서를 가짐으로써 본인 확인을 하고, 웹 사이트 인증에서 이용할 수도 있습니다.

 

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

완전성이란 정보의 정확성을 가리킵니다. 그것을 증명할 수 없다는 것은 정보가 정확한지 아닌지를 확인할 수 없음을 의미합니다.

예를 들어, 어떤 웹 사이트에서 콘텐츠를 다운로드 했다고 하면 클라이언트에 다운로드한 파일과 서버 상에 있는 파일이 정말로 같은 것인지 아닌지 모른다는 것입니다.

콘텐츠가 도중에 다른 내용으로 변경되었을지도 모릅니다.

공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부릅니다.

 

변조를 방지하려면?

MD5나 SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법입니다.

그러나 아쉽게도 이 방법으로 확실히 확인할 수 있는 것은 아닙니다. 확실히 방지하기에는 HTTPS를 사용할 필요가 있습니다.

SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있습니다.

HTTP만으로는 완전성을 보증하는 것이 어렵기 때문에 다른 프로토콜을 조합함으로써 실현하고 있습니다.

 

 

[ HTTPS ]

HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS(HTTP Secure)라고 부릅니다.

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

 

보통 HTTP는 직접 TCP와 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL와 통신하고 SSL이 TCP와 통신하게 됩니다.

SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용할 수 있게 됩니다.

 

공통키 암호화 방식

암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 부릅니다.

공통키 암호화 방식은 상대방에게 키를 넘겨주지 않으며 안됩니다.

 

키 배송 문제

• 키를 보내면 도청될 가능성이 있다.
• 키를 보내지 않으면 복호화 할 수 없다.
• 애초에 키를 안전하게 보낼 수 있다면 틀림없이 데이터도 안전하게 보낼 수 있다.

네트워크를 사용해서 키를 넘겨줄 때 통신이 도청되어 공격자에게 키를 빼앗기게 되면 암호화의 의미가 없게 됩니다.

또한 받은 키를 안전하게 보관하기 위한 노력을 하지 않으면 안됩니다.

 

공개키 암호화 방식

공통키 암호의 문제를 해결하려고 한 것이 공개키 암호라는 방식입니다.

SSL에서는 공개키 암호화 방식이라 불리는 암호화 방식을 채용하고 있습니다.

 

공개키 암호에서는 서로 다른 두 개의 키 페어(쌍)을 사용합니다. 한쪽은 비밀키(private key)라 부르고 다른 한쪽은 공개키(public key)라고 부릅니다.

공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 합니다. 그리고 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시합니다.

이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해서 키를 빼앗길 걱정은 없습니다.

 

공개키 암호화 방식의 약점

공개키가 진짜인지 아닌지를 증명할 수 없다는 것입니다.

예를 들면, 어떤 서버와 공개키 암호를 사용해서 통신을 시작하려 할 때 수신한 공개키가 본래 의도한 서버가 발행한 공개키인지를 어떻게 증명할 수 있을까요??

이 문제를 해결하기 위해 인증 기관(CA:Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있습니다. 인증기관이란 클라이언트와 서버가 모두 신뢰하는 제3자 기관입니다.

 

인증 기관 이용 절차

1. 서버의 운영자가 인증 기관에 공개키를 제출합니다.
2. 인증 기관은 제출된 공개키에 디지털 서명을 하고 공개키 인증서에 서명이 끝난 공개키를 담습니다.
3. 서버는 인증 기관에 의해 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신을 합니다.
4. 증명서를 받은 클라이언트는 증명 기관의 공개키를 사용해서 서버의 공개키를 인증한 것이 진짜 인증 기관이라는 것과 서버의 공개키가 신뢰할 수 있다는 것을 알 수 있습니다.

인증 기관의 공개키는 안전하게 클라이언트에 전달되지 않으면 안되므로. 많은 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 제품을 내놓고 있습니다.

 

EV SSL 증명서

EV SSL 증명서는 세계 표준의 인정 가이드라인에 의해서 발행되는 증명서 입니다.

증명서의 역할은 서버가 올바른 통신 상대임을 증명하는 것이지만, 상대방이 실제로 있는 기업인지를 확인하는 역할도 있습니다. 그러한 역할을 가지 증명서를 EV SSL 증명서라고 합니다.

운영하는 조직의 실재성을 확인하는 방법을 엄격히 규정하고 있기 때문에 웹 사이트의 신뢰성을 더욱 더 높일 수 있습니다.

 

클라이언트 증명서

HTTPS 에서는 클라이언트 증명서도 이용할 수 있습니다.

클라이언트 증명서를 이용하여 서버 증명서와 같이 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증을 할 수 있습니다.

예를 들면, 은행 인터넷 뱅킹입니다. 로그인할 때 ID나 패스워드로 본인 확인을 할 뿐만 아니라 클라이언트 증명서를 요구하여 특정 단말기에서 엑세스하는지 아닌지를 확인할 수 있습니다.

 

문제점

1. 증명서의 입수와 배포
2. 유저가 클라이언트 증명서를 install할 필요가 있습니다. 여러 유저가 인스톨 작업을 해야 하는 것도 큰 일 입니다.
3. 클라이언트 인증서는 어디까지나 클라이언트의 실재를 증명할 뿐, 사용자의 존재 유무를 증명하는 증명서는 아닙니다.
4. 클라이언트 증명서가 들어간 컴퓨터를 사용할 권한이 있다면 누구든지 클라이언트 증명서를 이용할 수 있다.

 

자기 인증 기관 발행 증명서

독자적으로 구축한 인증 기관을 자기 인증 기관이라 부릅니다.

OpenSSL 등의 소프트웨어를 사용하면 누구든지 인증 기관을 구축 할 수 있습니다.

 

문제점

자기 인증 기관이 발행한 서버 증명서는 위장의 가능성을 불식할 수 없는 문제가 있습니다.

자기 인증 기관 증명서를 사용하면 통신은 암호화되어 있어도 위장하고 있는 가짜 서버와 통신하고 있을 가능성이 있습니다.

 

SSL의 약점?

HTTPS에도 문제가 있습니다. 바로 SSL를 사용하면 처리가 늦어지게 된다는 점입니다.

1. CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려진다.
2. SSL은 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서는 암호화나 복호화를 위해 계산을 할 필요가 있습니다.

최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, http와 https의 속도는 점점 차이가 없어질 것이며 둘 차이의 체감속도는 더욱 감소할 것으로 보여집니다.

현재도 많이 줄어들었지만 앞으로도 SSL의 약점은 통신과 하드웨어의 발전에 따라 점점 줄어들 것 같습니다.

 

부족한 제 글 읽어주셔서 감사합니다. 오늘도 좋은 하루 되세요!!

 

참고자료

그림으로 배우는 HTTP&Network Basic

https://curryyou.tistory.com/207