HTTP와 HTTPS

HTTP(Hyper Text Transfer Protocol)

WWW(World-Wide-Web)기반 서비스에서 웹 서버와 WWW 클라이언트(웹 브라우저) 간 통신을 위해 사용하는 네트워크 프로토콜

일반적으로 80번 포트를 사용한다. 클라이언트가 80번 포트를 이용해 데이터를 요청(Request)하면 웹 서버는 80번 포트로 들어온 요청에 응답(Response)하는 방식으로 통신한다.

HTTP 요청(Request) 메시지와 응답(Response) 메시지는 크게 Start line, Headers, Body 부분으로 구성되어 있다.

• Start line : Method 방식, 타겟 URL, HTTP 버전 등의 정보
• Headers : Request와 Response 메시지 메타 정보
• Body : 실제 Request와 및 Response 메시지 내용

HTTP는 직관적이다. 요청 및 응답 메시지(HTML 파일, 텍스트 데이터, 이미지 및 파일 데이터 등)를 Body에 직접 붙여 전달한다. 따라서 데이터를 빠르고 쉽게 주고 받을 수 있다.

HTTPS(Hyper Text Transfer Protocol over Secure-Socket-Layer)

HTTP 프로토콜에 대해 SSL 암호화 통신 기능을 추가한 네트워크 프로토콜

HTTP는 웹 서버와 클라이언트(브라우저) 간 통신을 제약 없이 자유롭게 진행했다면, HTTPS는 웹 서버와 클라이언트(브라우저) 간 통신이 암호화되므로 제 3자의 개입이나 위, 변조를 막을 수 있다.

일반적으로 443번 포트를 사용한다. 또한 URL이 http://로 시작하는 HTTP 프로토콜과 달리, HTTPS 프로토콜은 https://로 시작하므로 URL을 확인하면 어떤 웹 사이트에서 HTTPS 프로토콜을 사용하는지 알 수 있다.

SSL(Secure Socket Layer)

웹 서버와 클라이언트 간 통신을 공인된 제 3자 인증 기관 CA(Certificate Authority)에서 인증하여 보안을 강화하는 방법

• SSL은 OSI 7계층의 응용 계층과 표현 계층 중간에 독립적으로 존재한다. 응용계층이 SSL로 데이터를 전송하면 SSL은 이를 암호화하여 TCP로 보낸 뒤 이것이 외부 인터넷으로 전달된다. 수신 역시 TCP로부터 데이터를 수신받은 SSL은 이를 복호화하여 응용계층으로 전달한다.
• 전송 계층 보안(Transport Layer Security, TLS)은 조금 더 진화된 버전의 SSL이다. 오늘날 대부분 TLS 방식을 이용하지만 SSL이 더 많이 알려져있기때문에 실제로는 TLS를 쓰고 용어만 SSL이라고 한다.

공개키 암호화 방식

• 데이터를 암호화(Encrypt)하고 암호화된 데이터를 다시 평문으로 원상복구하는 복호화(decrypt) 과정에서 각각 서로 다른 키(Key)를 사용한다.
• A키를 이용해 암호화한 데이터는 B키가 있어야 복호화하여 해석할 수 있다. 두 키는 쌍을 이룬다.
• 암호화 키(공개키)는 모두에게 공개되어 있기 때문에 누구나 암호화할 수 있다.
• 다만 복호화 키(비밀키)는 해당 데이터를 열람하고 수정할 권한이 있는 호스트만 각자 개인의 비밀키를 갖고 있다. 따라서 권한이 있는 자만 데이터를 읽을 수 있다.

공개키 암호화의 특성을 이용한 전자 서명

위의 공개키 암호화 방식을 응용하여 정보를 제공한 자의 신원을 보장할 수 있는 방법이 있다.

• 비밀키 소유가 자신의 비밀키를 이용해 데이터를 암호화하고, 이 데이터를 공개키와 함께 배포한다.
• 데이터를 수신한 자는 함께 수신한 공개키를 이용해 데이터를 복호화하여 접근할 수 있다.

기존의 공개키 암호화 방식에서는 공개키로 암호화한 뒤 비밀키로 복호화했다면 전자 서명에서는 반대로 비밀키로 암호화한 뒤 공개키로 복호화한다. 이 방법은 언뜻 보면 누구나 공개키를 이용해 데이터를 읽어 위, 변조할 수 있어 위험해 보인다. 하지만 암호화된 데이터를 특정 공개키로 복호화할 수 있다는 것은 해당 데이터가 특정 공개키와 쌍을 이루는 특정 비밀키로 암호화되어있다는 것을 의미한다. 따라서 데이터를 제공한 자의 신원을 보장할 수 있다.

SSL을 이용한 통신 과정

1. Handshake

   1. 클라이언트가 서버에 접속한다.

      • 전송하는 정보 : 클라이언트가 생성한 랜덤 데이터, 암호화 방식 협상을 위한 제안, 세션 아이디
      • 랜덤 데이터는 실질적인 요청 및 응답 메시지 암호화, 복호화를 위해 사용됨
      • 클라이언트 측에서 가능한 암호화 방식의 종류를 서버 측에 제시
      • 이후 같은 세션에서는 SSL 핸드 쉐이킹을 생략하기 위해 세션 식별자를 함께 보냄

   2. 서버는 클라이언트의 요청에 응답한다.

      • 전송하는 정보 : 서버가 생성한 랜덤 데이터, 클라이언트의 암호화 방식 중 서버가 선택한 암호화 방식 명시, 인증서
      • 랜덤 데이터는 실질적인 요청 및 응답 메시지 암호화, 복호화를 위해 사용됨
      • 클라이언트가 제시한 암호화 방식 중 가능한 암호화 방식을 선택함
      • 서버가 자기 자신임을 인증하기 위한 인증서

   3. 클라이언트는 서버의 인증서를 통해 서버의 신원을 판별한다.

      • 클라이언트는 서버의 인증서가 신뢰할 수 있는 CA에서 인증된 것인지 확인한다.
      • 신뢰할 수 있다면 해당 CA의 공개키로 서버의 인증서를 복호화한다.
      • 복호화가 성공했다는 것은 CA의 공개키와 쌍을 이룬 해당 CA의 비밀키로 암호화가 되었다는 것을 의미하므로 서버의 신원을 확실하게 믿을 수 있다.

   4. 실제 HTTPS 통신 메시지를 암호화하기 위해 클라이언트와 서버의 랜덤 메시지를 조합하여 pre master secret 키를 생성한다.

      • pre master secret 키는 대칭키이므로 이를 주고받기 위해 다시 공개키 방식을 이용한다. 서버의 공개키로 pre master secret 키를 암호화하여 보내면 클라이언트는 이를 자신의 비밀키로 복호화하여 메시지를 읽을 키(session key)를 획득한다.

2. 세션

   • 클라이언트와 서버가 실제 데이터를 주고 받는다.
   • handshake 단계에서 공유한 session key(대칭키)를 이용해 메시지를 암호화 및 복호화한다.
   • 대칭키와 공개키를 혼용하는 이유 : 공개키 방식이 상대적으로 많은 연산을 필요로하기 때문에 연산을 최소화하기위해 실제 데이터에 접근하기 위한 대칭키만 공개키로 암호화하는 것!

3. 세션 종료

   • SSL 통신이 끝났음을 서로에게 통지한다.
   • session key는 폐기한다.

HTTP Vs HTTPS

1. HTTPS 프로토콜과 HTTP 프로토콜의 가장 큰 차이는 보안이다.

   • HTTPS 프로토콜은 SSL 암호화 방식을 이용해 요청과 응답 주체를 인증할 수 있고, 전송하는 데이터도 암호화 되어있으므로 해독하여 위, 변조할 수 없다. 즉, 데이터의 무결성을 보장한다.
   • 사용자의 개인정보나 결제 정보 등과 같이 민감하고 중요한 정보를 전송해야할 경우 HTTPS 프로토콜을 이용해야 한다.

2. 부가적인 차이는 SEO 품질이다.

   • SEO(Search Engine Optimization, 검색 엔진 최적화) : 구글 등의 검색 엔진에서 웹사이트가 잘 검색되고 노출될 수 있도록 검색을 최적화 하는 전략
   • 검색 엔진 구글은 HTTPS 프로토콜을 이용하는 웹 사이트에 대해 SEO 가산점을 제공하여 웹 사이트들이 HTTPS 프로토콜을 이용하도록 유도하고 있다.
   • 나아가 크롬과 같은 브라우저에서는 HTTP 프로토콜을 이용하거나 신뢰할 수 없는 인증서를 이용해 통신할 경우 ‘안전하지 않음’ 이라는 메시지를 출력함으로써 사용자가 HTTP 웹 사이트를 접속하는 것을 간접적으로 막고 있다.
   • 또한 구글에서 지원하는 AMP(Accelerated Mobile Pages, 가속화된 모바일 페이지) 혜택을 받기 위해서도 HTTPS 프로토콜을 사용해야 한다.
3. 미묘한 성능 차이가 존재할 수 있으나 기술의 발달로 체감할 수 없는 수준이 되거나 오히려 HTTPS가 더 좋은 성능을 보이기도 하므로 문제가 없는 수준이다.

References

생활코딩 - HTTPS와 SSL 인증서