7장 웹을 안전하게 지켜주는 HTTPS

nudge411·2021년 7월 23일
0
해당 내용은 그림으로 배우는 Http&Network Basic 책내용을 정리한것 입니다.

1. HTTP의 약점

  • 평문(암호화 하지 않은) 통신이기 때문에 도청가능
  • 통신 상대를 확인하지 않기 때문에 위장가능
  • 완전성을 증명할 수 없기때문에 변조 가능
  • 이 약점은 암호화하지 않는 프로토콜에 공통적인 단점이다.
  1. 평문이기 때문에 도청 가능
    • HTTP통신 내용은 자신을 암호화하는 기능없기 때문에 통신 전체가 암호화되지 않는다.
    • TCP/IP는 도청 가능한 네트워크
      • TCP/IP 구조의 통신내용은 전부 통신경로 도중 엿볼수 있다.
      • 네트워크 상에 흐르고 있는 패킷을 수집하는 것만으로 도청이 가능하다.
      • 패킷 해석을 위해 패킷캡처, 스니퍼 등의 툴을 사용한다.
    • 암호화로 도청을 피하다
      1. 통신 암호화
        • SSL, TSL 프로토콜을 조합함으로 HTTP 통신내용 암호화 가능
        • SSL 로 안전한 통신소를 확립하고 통신을 수행한다
        • SSL 을 조합한 HTTP를 HTTPS 나 HTTP over SSL 라고한다.
      2. 콘텐츠 암호화
      3. HTTP 메세지에 포함되는 콘텐츠만 암호화 한다. - 이 경우 클라이언트에서 HTTP 메세지를 암호화하여 출력하는 처리가 필요하다
  2. 통신 상대를 확인하지 않기 때문에 위장가능
    • HTTP는 통신상대를 확인하지 않는다.
    • 누구나 리퀘스트 할 수 있다.
      • 요청을 보낸 곳의 웹서버가 의도한 응답을 보내야 하는 웹서버 인지 아닌지를 확인 할 수 없다.
      • 응답을 반환한 곳의 클라이언트가 의도한 요청을 보낸 클라이언트 인지 아닌지 확일할 수 없다.
      • 통신하고 있는 상대가 접근이 허가된 상대인지 확인할수 없다.
      • 어디의 누가 요청했는지 알수 없다.
      • 의미없는 요청또한 수신하게된다. Dos 공격을 방지할 수 없다.
    • 상대를 확인하는 증명서
      • SSL로 상대를 확인할 수 있다.
      • SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공한다.
      • 증명서는 신뢰할수 있는 제 3자가 발행하고, 서버나 클라이언트가 실재하는 사실을 증명한다.
      • 증명서를 위조하는 것은 기술적으로 어렵다.
      • 통신 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 상대를 판단할 수 있다.
  3. 완전성을 증명할 수 없기 때문에 변조 가능
    • 완전성이란 정보의 정확성을 뜻한다. 증명할 수 없다는 것은 정보가 정확하지 아닌지를 확인할 수 없다는 의미이다.
    • 수신한 내용이 다를지도 모른다
      • 요청과 응답사이에 메세지가 변조 되어도 이 사실을 인지할수 없다.
      • 이와 같이 공격자가 도중에 요청이나 응답을 빼앗아 변조 공격을 중간자 공격(Man-in-the-Middle)이라고 한다.
    • 변조를 방지하려면?
      • MD5 나 SHA-1 등의 해시값을 확인하는 방법과 디지털 서명을 확인하는 방법이 있다.
      • 확실히 방지하기 위해선 HTTPS를 사용해야한다
      • SSL에는 인증, 암호화, 다이제스트 기능을 제공한다
      • HTTP만으로는 완전성 보증이 어렵기 때문에 다른 프로토콜을 조합하고 있다.

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

  1. HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS
    • HTTP에 암호화나 인증 등의 구조를 더한것을 HTTPS(HTTP Secure) 라고한다.
    • URI 에 https:// 를 사용한다.
  2. HTTPS는 SSL의 껍질을 덮어쓴 HTTP
    • HTTPS는 새로운 애플리케이션 계층의 프로토콜은 아니다.
    • HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer) 이나 TLS 라는 프로토콜로 대체 하는것.
    • 보통 HTTP는 TCP와 직접 통신하지만, SSL을 사용한 경우 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
    • SSL을 사용하면 HTTP는 암호화, 증명서, 완전성 보호를 갖추게된다.
  3. 상호간의 키를 교환하는 공개키 암호화 방식
    • SSL은 공개키 암호화방식을 채용하고 있다.
    • 현재의 암호는 알고리즘이 공개되어 있고 키를 비밀이 부침으로써 안정성을 확보한다.
    • 암호화나 복호화 할때 키를 사용하며, 키가 없다면 암호를 풀수 없다.
    • 반대로 키가 있다면 그 누구라도 암호를 풀수 있게된다.
    • 공통키 방식은 상대방에게 키를 같이 넘겨주어야만 한다.
    • 이 과정에서 공통키 자체가 도청 될수있고, 키를 안전하게 보관하기 위한 노력도 해야한다.
    • 이러한 공통키암호 문제를 해결하게 위해 공개키 암호 방식이 나왔다.
    • 공개키는 키가 한쌍을 이루고 있다.
    • 한쪽은 공개키, 다른 한쪽을 비밀키 이다.
    • 상대방의 공개키를 사용하여 암호화한 데이터를 전송한다.
    • 그리고 상대방은 받은 데이터를 비밀키로 복호화 한다.
    • 이 방식은 복호화에 필요한 비밀키를 통신으로 보내지 않기때문에 도청에 의해 키가 유출될 걱정은 없다.
    • 또 암호화된 정보에서 평문을 구하는것은 수학적으로 매우 힘든일이다.
    • HTTPS는 공통키 암호화 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템이다.
    • 공개키 암호는 공통키 암호에 비해서 처리속도가 늦다.
    • 키를 교환할때는 공개키 암호를 사용하고 그후의 통신에서는 공통키 암호를 사용한다.
  4. 공개키가 정확한지 아닌지를 증명하는 증명서
    • 공개키 암호에도 문제점이 있는데, 그 공개키가 진짜인지 아닌지를 증명할수 없다.
    • 문제의 해결을 위해서 인증기관(CA)와 그 기관이 발행하는 공개키 증명서가 이용되고 있다.
    • 인증기관 이란 클라이언트와 서버가 신뢰하는 제 3자 기관이다.
    • 먼저 서버의 운영자가 인증기관에 서버의 공개키를 제출한다.
    • 인증기관은 제출된 공개키에 디지털서명을 하고 서명이 끝난 공개키를 만든다.
    • 공개키 인증서에 서명이 끝난 공개키를 담는다.
    • 서버는 인증기관에 의해 작정된 공개키 인증서를 클라이언트에 전송하고 공개키 암호로 통신한다.
    • 공개키 인증서는 디지털 증명서, 증명서 등으로 불린다.
    • 증명서를 받은 클라이언트는 증명기관의 공개키를 사용해서 서버의 공개키를 인증한 것이 진짜 인증기관 이라는 것과 서버의 공개키가 신뢰할수 있음을 알수있다.
    • 인증기관의 공개키는 안전하게 클라이언트에게 전달되어야한다.
    • 통신중에는 어떤 방법을 사용한다 하더라도 안전하게 전달하는 것은 어렵다.
    • 때문에 많은 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 제품을 내놓고 있다.
    • 조직의 실제성을 증명하는 EV SSL 증명서
    • 보통 증명서의 역할은 서버가 올바른 통신 상대임을 증명하는 것이다.
    • 동시에 상대방이 실제로 있는 기업인지를 확인하는 역할도 있는데, 그런 역할을 가진 증명서를 EV SSL라고 한다.
    • EV SSL 증명서는 세계표준의 인정 가이드라인에 의해서 발행되는 증명서이다.
    • 운영하는 조직의 실재성을 확인하는 방법을 엄격히 규정하고 있기 때문에 웹 사이트의 신뢰성을 더욱 더 높일수 있다.
    • 브라우저의 주소창 색이 녹색으로 변하면 EV SSL 증명서로 증명된 웹 사이트인걸 알 수 있다.
    • 주소창의 옆에는 SSL증명서에 기재된 조직명 및 증명서 인증기관이 표시된다.
    • 클라이언트를 확인하는 클라이언트 증명서
    • HTTPS에서는 클라이언트 증명서도 이용할 수 있다.
    • 서버가 통신하고 있는 클라이언트가 의도한 클라이언트 인지 증명한다.
    • 클라이언트 인증은 보안상 매우 높은 인증을 필요로 할때 특정 용도로 사용된다.
    • 은행 인터넷 뱅킹, 공동인증서 등등이 있다
    • 클라이언트는 증명서는 클라이언트의 실재를 증명할뿐, 사용자의 존재 유무를 증명하는 증명서는 아니다.
  5. 안전한 통신을 하는 HTTPS의 구조
    • 205-207page 그림 참조
    • SSL과 TSL
    • SSL3.0 을 기반으로 TSL1.0 이 개발되었다.
    • 현재 주류는 SSL3.0, TSL.1.0 이다.
    • SSL을 사용하면 처리가 늦어지게된다
    • 이유는 모든 정보가 암호화와 복호화처리가 필요하기 때문이다.
    • 또한 HTTP 통신 이외의 SSL 에 필요한 통신이 추가되기 때문이다.
    • 해결 방법 으로는 SSL 처리를 위한 전용하드웨어를 두는 방법등이 있다.
profile
잊기 위한 기록을 합니다.

0개의 댓글