HTTPS vs. HTTP

 

평소 URL 주소창에 LOCK표시가 되어있으면 HTTPS, 아니면 HTTP이라고 인식만 할 뿐 이에 대한 자세한 내용은 알지 못하고 넘어갔다. 오늘은 이에 대한 본격적으로 분석해보고자 한다.

 

HTTP란?

HTTP는 하이퍼 텍스트 전송 프로토콜(Hypertext Transfer Protocol)의 약자이다. 서로 다른 시스템들(서버와 클라이언트) 사이에서 통신을 주고받게 해주는 가장 기초적인 프로토콜이고, 80번 포트를 사용하고 있다. 따라서 HTTP 서버가 80번 포트가 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보낸다.

HTTP는 애플리케이션 레벨(7계층인 응용계층)의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않은 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

HTTPS란?

HTTPS는 하이퍼 텍스트 전송 프로토콜 보안(Hypertext Transfer Protocol Secure)의 약자이다. 일반 HTTP 프로토콜의 문제점은 브라우저로 전송되는 정보가 암호화되지 않는다는 것이다. 이 말은 즉슨, 데이터가 쉽게 도난당할 수 있다는 뜻이다. HTTPS 프로토콜은 SSL(보안 소켓 계층)을 사용함으로써 이 문제를 해결했다. SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을 때 이것이 도난당하는 것을 막아준다. 

SSL(Secure Socket Layer)란 보안 소켓 계층을 이르는 것으로 인터넷 상에서 데이터를 안전하게 전송하기 위한 인터넷 암호화ㅏ 통신 프로토콜을 말한다. SSL은 전자상거래 등의 보안을 위해 넷스케이프에서 처음 개발되었고, 시간이 지나 IETF에 의해 SSL 3.0을 이용해 TLS(Transport Layer Security)로 표준화하였다. 

 

SSL/TLS는 사실 어느 계층에 속해있다고 말하기 어렵다. SSL/TLS는 응용계층과 전송계층 사이에서 동작하는 독립적인 프로토콜이라고 생각하면 좋다. SSL의 경우 응용계층(Application Layer)의 HTTP 프로토콜에서 사용자의 데이터를 받고 전송계층(Transport Layer)으로 캡슐화되기 전에 SSL 프로토콜에 의해서 사용자의 데이터가 암호화된다. 그리고 서버는 전송계층에서 세그먼트를 받아 SSL 계층에서 데이터를 복호화하여 응용계층까지 보낸다. 즉 우리는 SSL 프로토콜만 적용하면 애플리케이션은 SSL을 TCP로 인식하고, TCP는 SSL을 애플리케이션으로 인식하는 것처럼 통신하기 때문에 우리가 별도로 통신에 대해 손댈 것은 없다.

 

SSL은 TCP 위에서 Record Protocol을 통해 실질적인 보안서비스를 제공하고 Handshake Protocol, Change Cipher Spec Protocol, Alert Protocol을 통해 SSL 동작에 관한 관리를 한다.

 

1. Record Protocol

데이터의 압축을 수행하여 안전한 TCP 패킷으로 변환하고, 데이터 암호화 및 무결성을 위한 메시지 인증을 수행하는 프로토콜로 Handshake Protocol, Change Chipher Spec Protocol, Alert Protocol을 감싸는 역할을 한다.

 

2. Change Cipher Spec Protocol

암호화 알고리즘과 보안 정책을 송수신 측 간에 조율하기 위해 사용하는 프로토콜로 프로토콜의 내용에는 단 하나의 바이트, 언제나 1이라는 값이 들어간다.

 

3. Alert Protocol

2바이트로 구성되며, 첫번째 바이트에는 warning 또는 fatal이 들어가게 되고 두번째 바이트에는 Handshake, Change Cipher Spec, Record Protocl 수행 중 발생하는 오류 메시지가 들어가게 된다.

• Warning: 주의해야 하는 문제, 연결 미종료
• Fatal: 매우 중요한 문제, 연결 종료

4. Handshake Protocol

암호 알고리즘 결정, 키 분배, 서버 및 클라이언트 인증을 수행하기 위해 사용되는 프로토콜이다.

 

참고) HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다. 

공개키/개인키

HTTPS는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다. 공개키와 개인키는 서로를 위한 1쌍의 키이다.

• 공개키(Public Key): 모두에게 공개 가능한 키
• 개인키(Private Key): 나만 가지고 알고 있어야 하는 키

공개키와 개인키로 암호화하면 다음과 같은 효과를 얻을 수 있다.

• 공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. 즉 개인키는 나만 가지고 있기 때문에 나만 볼 수 있다.
• 개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다. 즉 공개키는 모두에게 공개되어있으므로 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

HTTPS의 동작 과정

HTTPS는 SSL과 같은 프로토콜을 사용하여 공개키/개인키 기반으로 데이터를 암호화하고 있다. 데이터는 암호화되어 전송되기 때문에 임의의 사용자가 데이터를 조회하여도 원본의 데이터를 보는 것은 불가능하다. 

그렇다면 이제 서버는 클라이언트가 요청을 보낼 때 암호화를 하기 위한 공개키를 생성해야하는데, 일반적으로 아래의 과정을 거쳐 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급받고 있다. 

1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급한다.
2. CA 기업에 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청한다.
3. CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고 CA 기업의 개인키로 암호화하여 A 기업에 인증서를 제공한다.
4. A기업은 클라이언트에게 암호화된 인증서를 제공한다.
   • 서버는 클라이언트와 Handshake를 거쳐 인증서 제공
5. 브라우저(클라이언트)는 CA 정보 확인 후 CA기업의 공개키를 미리 다운 받고 있어서 이로 암호화된 인증서를 복호화한다.
6. 암호화된 인증서를 복호화하여 얻은 CA기업의 공개키로 데이터를 암호화하여 요청을 전송한다.

암호화된 인증서는 CA의 개인키로 암호화되었기 때문에 신뢰성을 확보할 수 있고, 클라이언트는 A 기업의 공개키로 데이터를 암호화하였기에 A기업만 복호화하여 원본의 데이터를 얻을 수 있다.

HTTPS는 이러한 공개키/개인키 기반의 대칭키 암호화 방식을 활용하여 안전성을 확보하고 있다.

 

대신 비대칭키와 대칭키를 섞어서 쓴다. 비대칭키만 사용하면 서버에 부담이 가중되기 때문이다. 그래서 대칭키를 공유할 때 비대칭키를 사용함으로써 보안을 유지한다. 처음에 Handshake를 할 때 주고받은 무작위 데이터를 이용해, 클라이언트는 임시키를 만든다. 이 임시키를 이용해 서버의 공개키로 암호화하여 서버로 보내진 다음 양쪽에서 일련의 과정을 거쳐서 동일한 대칭키가 생성된다. 이 대칭키는 서버와 클라이언트만 가지기 때문에 제 3자가 알아챌 우려가 줄어든다.

 

[요약]

1. 암호화 - 공개키, 복호화 - 비공개키 : 진짜 데이터를 암호화하여 보호하기 위한 목적

2. 암호화 - 비공개키, 복호화 - 공개키 : 인증을 위한 목적, 서버에서 비공개키로 데이터를 암호화해서 보냈고 클라이언트에서 공개키로 복호화가 된다면 최소한 해당 서버는 클라이언트 입장에서 신뢰할 수 있다는 인증과정을 거친다.

 

 

HTTPS의 장점 1. 보안

둘의 가장 큰 차이는 SSL 인증서이다. 사실 HTTPS는 HTTP프로토콜에 보안 기능을 추가한 것이다. 보안 기능은 생각보다 중요하다. 특히 신용카드 정보나 비밀번호 등 사용자들의 민감한 정보들을 다루는 경우에 중요하다.

 

SSL 인증서는 사용자가 사이트에 제공하는 정보를 암호화한다. 이렇게 전송된 데이터는 중간에서 누군가 훔쳐낸다고 하더라도 데이터가 암호화되어있기 때문에 해독할 수 없다. 그 외에도 HTTPS는 TLS(전송 계층(4계층) 보안) 프로토콜을 통해서도 보안을 유지한다. TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증기능도 제공한다.

 

HTTPS의 장점 2. SEO

만약 웹사이트에 전자상거래 기능도 없고 방문자들의 민감한 정보를 다루지도 않는다면, HTTPS로 전환할 필요성이 크게 느껴지지 않는다. 하지만 HTTPS의 장점은 보안상 우위에만 있는 것이 아니다. 사실 HTTPS로 전환하게 되면 검색엔진 최적화에 있어서도 큰 혜택을 볼 수 있다. 이는 앞서 말했듯이 구글이 HTTPS 웹사이트에 가산점을 주는 이유 때문이기도 하지만, 사용자들이 결국에는 가장 안전하다고 생각하는 사이트를 더 많이 방문하기 때문이기도 하다.

 

또한 가속화된 모바일 페이지(AMP, Accelerated Mobile Pages)를 만들고 싶을 때도 HTTPS 프로토콜을 사용해야 한다. 여기서 AMP란 모바일 기기에서 훨씬 빠르게 콘텐츠를 로딩하기 위한 방법으로 구글이 만든 것이다. AMP는 HTML에서 불필요한 부분을 없앤 것이다. 구글의 SERP(검색결과 페이지)를 보면 스마트폰과 태블릿의 사용자들이 모바일에서 사용하기 편하도록 AMP 콘텐츠들이 두드러져 보이는 것을 볼 수 있다.

모바일 친화적인 웹사이트를 만드는 것과 모바일 검색 순위 및 지역에 SEO를 증가시키는 것이 점점 더 중요해지고 있는 요즘, HTTP를 HTTPS로 전환하는 것이 필수다.

 

HTTPS로 전환하려면?

HTTP에서 HTTPS로 전환하게 되면 좋은 점들도 많이 있지만 실제로 그렇게 하는 과정에서는 여전히 몇 가지 잠재적인 문제들도 있다. HTTPS로 전환할 때 알아둬야하는 팁이 몇 가지 있다.

 

- 사이트가 HTTP에서 HTTPS로 바뀌었음을 구글에게 알려주세요.

사이트가 HTTPS로 전환됐음을 구글이 자동으로 알 수 없다.

 

- SSL 인증하는 것에는 여러 종류의 인증서가 있다.

예를 들면 싱글 도메인, 멀티플 도메인, 와일드 카드 SSL 인증서 등이 있다.

• 싱글 도메인(Single Domain) 인증서는 한 개의 도메인 또는 그 서브 도메인을 위해서 발행되는 것이다.
• 멀티플 도메인(Multiple Domain) 인증서는 통합 커뮤니케이션 인증서(Unified Communications)라고도 불리는데, 메인 도메인 이름을 비롯해서 최대 99개까지의 대체 도메인 이름(Subject Alternative Names)을 보호할 수 있게 해준다.
• 와일드카드(Wildcard) 인증서는 웹사이트 URL은 물론이고 서브 도메인도 무제한으로 보호할 수 있게 해준다.

- 모든 리소스에 대해서는 상대 경로(Relative URL)를 사용해야 한다.

상대 경로(Relative URL)를 사용하게 되면, 해당 웹사이트에 사용된 모든 요소들이 안전한 프로토콜을 사용하는 등 동일한 도메인 안에 존재하고 있다는 것을 알려주는 것이다. 

HTTPS를 사용해서 구축한 사이트를 구글이 크롤링(Crawling)하는 것을 막지 않도록 해야 한다. 일반적으로 웹사이트에는 로봇이 접근하는 것을 방지하는 정책을 기술한 robot.txtx라는 파일을 두고 있다. 그런데 이 파일에서 구글의 크롤링을 차단하고 있다면, 여러분의 SEO에 있어서 손해를 입게 되고 검색 순위에 있어서도 좋은 평가를 받지 못한다. 테스트 버전의 서버를 업데이트하는 과정에서 이 파일을 수정하지 않아서 이런 일이 벌어지는 경우가 있다.

 

- 검색엔진이 여러분의 웹사이트에 있는 페이지들을  인덱싱하는 것을 혀용해야 한다.

물론 검색엔진이 이런 일을 하는 걸 막을 수 있는 선택권이 있지만 그렇게 하면 결국엔 SEO를 개선하려는 노력이 물거품이 되고, 검색 결과에서 아예 사라질 수도 있다. 그리고 그걸 되돌리려면 많은 시간이 걸릴 수도 있다.

 

- HTTP에서 HTTPS로 전환하는 과정을 세심하게 추적해야 한다.

 구글 웹마스터 툴(Google Webmaster Tools)을 비롯한 분석 소프트웨어를 이용하면 모든 것들이 원활하게 진행되고 있는지를 확인할 수 있다. 그리고 문제가 발생했다면 최대한 빠르게 조치를 해서, SEO가 손상되는 일이 없도록 한다.

---

Reference

• http://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/
• https://coding-start.tistory.com/208
• https://www.youtube.com/watch?v=H6lpFRpyl14&list=WL&index=20