HTTP와 HTTPS의 차이란?

웹 페이지를 돌아다니다 보면 주소창에 http 혹은 https라고 써있는 걸 볼 수 있다.

그리고 http가 적힌 사이트로 들어가면 안전하지 않음 이라는 문구가 나오는 걸 볼 수 있다.

그럼 이것들은 각각 무엇이고 둘의 차이는 무엇인지 궁금해진다.

 

먼저 http는 Hypertext Transfer Protocol의 약자로, 하이퍼텍스트 전송 프로토콜이란 뜻이다.

여기서 2개의 키워드가 신경쓰인다. 하이퍼텍스트와 프로토콜이다. 둘은 각각 뭘까?

 

Hypertext를 떼어내서 보면 Hyper와 Text가 합쳐진 단어란 걸 알 수 있다. 각각의 사전적 정의는 아래와 같다.

 

Hyper : 과도하거나 지나침을 나타내는 접두어
Text : (모든 형태의) 글, 문서

이렇게 놓고 보면 하이퍼텍스트가 뭐하는 놈인지 알기가 애매하다. 과도한 글이나 문서? 뭔가가 지나친 글이나 문서?

이번엔 하이퍼텍스트 자체를 사전에 쳐보면 아래의 결과가 나온다.

 

Hypertext : 문장 중의 어구나 그것에 붙은 표제. 표제를 모은 목차 등이 서로 연결된 문자 데이터 파일
표제? 서책의 겉에 쓰는 책의 이름, 연설/담화 따위의 제목

 

뭔가 연결돼 있는 파일이라고 한다. 연결돼 있다는 건 문서나 글이 어떤 뭔가와 연결돼 있다는 뜻 같다.

하이퍼텍스트를 구글에 검색해보면 아래의 결과가 나온다.

 

사용자에게 내용의 비순차적 검색이 가능하도록 제공되는 텍스트. 문서 내의 특정한 단어가 다른 단어나 데이터베이스와 링크되어 있어 사용자가 관련 문서를 넘나들며 원하는 정보를 얻을 수 있음. 전자 사전·멀티미디어 데이터베이스·문장 작성 시스템 등에 응용됨.

일단 텍스트가 다른 단어 혹은 데이터베이스에 연결돼 있어서, 사용자가 이 텍스트를 통해 원하는 정보를 얻을 수 있도록 하는 것이라는 건 알겠다.

다음은 영문 위키백과에서 http를 설명하는 내용이다.

 

HTTP는 분산된 협업 하이퍼 미디어 정보 시스템을 위한 애플리케이션 계층 프로토콜이다. HTTP는 World Wide Web을 위한 데이터 통신의 기초다. 하이퍼 텍스트 문서에는 사용자가 쉽게 액세스 할 수 있는 다른 리소스에 대한 하이퍼 링크가 포함되어 있다.

또 프로토콜이란 단어가 나온다. 이번엔 애플리케이션 계층이라고 한다. 애플리케이션 계층이란 건 다른 계층들도 있다는 건가? 그럼 그 계층마다 프로토콜이 존재한다는 건가? 아니면 애플리케이션 계층이란 곳에만 프로토콜이 존재하는 건가?

아무튼 영문 위키백과에는 애플리케이션 계층(Application Layer)에 링크가 걸려 있다. 여기로 들어가면 아래의 내용이 있다.

 

애플리케이션 계층은 통신 네트워크에서 호스트가 사용하는 공유 통신 프로토콜 및 인터페이스 메서드를 지정하는 추상화 계층이다. 애플리케이션 계층 추상화는 컴퓨터 네트워킹의 표준 모델인 인터넷 프로토콜 스위트 (TCP / IP)와 OSI 모델 모두에서 사용된다.

아...또 프로토콜이 나왔다. 공유 통신 프로토콜과 인터페이스 메서드를 지정하는 추상화 계층....뭔 소린지.

본론으로 돌아가서, HTTP란 것은 프로토콜을 모르고선 이해할 수 없는 것 같다. 이번엔 프로토콜에 대해서 알아보자.

 

프로토콜의 사전적 정의는 외교, 의전, 통신 규약이란 뜻이다.

규약은 조직체 안에서 서로 지키도록 협의해서 정한 규칙이란 뜻이다.

즉, 프로토콜은 두 지점에서 서로 통신할 때 지켜야 할 규칙이란 뜻으로 생각된다.

구글에선 프로토콜을 아래와 같이 말하고 있다.

 

복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신 규약. 신호 송신의 순서, 데이터의 표현법, 오류(誤謬) 검출법 등을 정함.

프로토콜이 없으면 데이터 통신에 뭔가 불편함이 있는 듯하다.

하긴 약속이 없으면 불편한 게 한두 개가 아닌데, 데이터 통신도 다를 건 없나보다.

결론은 신호를 보낼 때 순서, 데이터를 어떻게 표현할지 등등을 정하는 것이 프로토콜이다. 프로토콜을 주제로 다루는 포스팅이 아니기 때문에 여기까지만 쓰고 넘어간다.

 

다시 돌아가서, HTTP는 분산된 협업 어쩌고를 위한 애플리케이션 계층 프로토콜이라고 했다.

그럼 HTTP는 애플리케이션 계층에서 사용되는 어떤 약속이지 않을까, 라고 생각해볼 수 있다.

즉, 데이터 통신 시 HTTP라는 약속을 지켜야 웹 페이지에서 데이터 통신을 할 수 있다는 걸 알 수 있다.

 

우리가 네이버, 유튜브 등 웹 사이트로 들어간다는 것은 네이버, 유튜브 등 회사의 서버에 접속해 그 페이지를 요청한다는 뜻이다.

웹 브라우저의 주소창에 naver.com이라는 주소를 입력하고 엔터를 치면, 네이버가 가진 어떤 컴퓨터에 저장된 웹 페이지를 가져와 우리에게 보여준다.

이 때 웹 페이지를 요청하는 웹 브라우저는 클라이언트(Client), 네이버가 가진 컴퓨터는 서버(Server)라고 한다.

그리고 클라이언트가 서버에게 웹 페이지를 달라고 하는 것은 요청(Request)이라고 하고, 이것에 포함된 웹 페이지 등 정보를 찾아서 클라이언트에게 주는 것을 응답(Response)이라 한다. 이 때 응답은 항상 정상적이진 않다. 가끔 404 Not Found 에러를 볼 수 있듯 에러를 응답으로 돌려줄 수도 있다.

여기서 클라이언트와 서버 간 데이터 전송에 사용되는 규칙이 HTTP다. 또한 우리는 HTTP란 걸 알 필요 없다. 그냥 사이트 url만 알고 입력할 손가락만 있으면 된다. 데이터를 요청하고 보여주는 건 크롬 같은 웹 브라우저가 하는 일이다.

 

그럼 HTTPS는 뭘까? HTTP에 S 하나 추가된 형태다.

S는 Secure의 약자고 안전이라는 뜻이 있다. 즉 안전한 HTTP란 것이다. 그럼 HTTP는 불안전하다는 뜻인가?

그래서인지 HTTPS에서 통신 프로토콜은 TLS(Transport Layer Security) 또는 SSL(Secure Sockets Layer)을 써서 암호화된다. 즉, HTTPS는 HTTP의 확장된 버전이라고 할 수 있다.

그럼 SSL과 TLS는 뭘 말하는 걸까?

 

SSL과 TLS는 클라이언트와의 네트워크를 통해 작동하는 서버, 시스템 등 사이의 인증 및 데이터 암호화를 제공하는 암호화 프로토콜이다. 즉, 클라이언트와 서버 간 인터넷을 통해 전송되는 데이터를 암호화해서, 우리가 전송하는 내용을 도청하는 사람이나 해커가 볼 수 없게 해준다는 뜻이다. 특히 비밀번호, 신용카드 번호, 이메일 같은 개인적이고 민감한 정보를 보호할 때 유용하다.

TLS 프로토콜은 1994년 넷스케이프에서 개발한 SSL에서 발전한 것으로, 주로 통신하는 둘 이상의 컴퓨터 사이에 개인정보 보호, 데이터 무결성을 제공하는 걸 목표로 한다.

1999년 RFC 2246에서 응용 프로그램의 독립 프로토콜로 처음 지정됐고, SSL 3.0과 직접 상호운용할 수 없었지만 필요한 경우 대체 모드를 제공했다. 현재 SSL 3.0은 이제 불안전하다고 간주되서 TLS 1.2를 써야 한다는 권장 사항이 생겼다.

 

TLS는 일반적으로 HTTP, FTP, SMTP 등의 애플리케이션 계층 프로토콜을 암호화하기 위해 TCP의 위에 구현되지만, UDP나 DCCP, SCTP에서도 구현할 수 있다. 이것은 데이터그램 전송 계층 보안(DTLS)라고 하며 RFC 6347, 5238, 6083에 지정되어 있다. RFC가 뭐고 뒤의 숫자가 뭔지는 추후 포스팅에서 다루겠다.

 

그럼 이 TLS는 왜 쓰는 것인가? 원래 데이터는 암호화되지 않은 상태로 인터넷을 통해 전송됐으며, 암호화된 경우엔 비밀번호 같은 민감한 정보를 위해 단편적으로 쓰였다.

1996년 RFC 1984에 의한 인터넷의 성장과 도청자와 해커같은 공격자의 기술이 생각보다 널리 퍼져있다는 것이 분명해짐으로 인해 개인 데이터를 보호해야 한다는 인식이 생겼다.

그 후 2014년 IAB는 프로토콜 설계자, 개발자, 운영자에게 암호화를 인터넷 트래픽의 표준으로 할 것을 요구하는 성명을 발표했다. 그래서 현재는 TLS가 없으면 로그인, 신용카드/개인의 세부 정보 등 민감한 정보를 타인이 쉽게 수집할 수 있고, 검색 기록이나 온라인 채팅, 화상 회의도 모니터링할 수 있다.

 

현재 우리가 쓰는 크롬, 사파리같은 주요 웹 브라우저의 최신 버전은 TLS를 지원하며, 웹 서버가 기본적으로 TLS를 지원하는 것이 보편화되어 있다.

그러니 클라이언트, 서버 간 통신에 보안을 섞어서 제대로 구현해야 한다면 TLS를 의무적으로 사용해야 한다.

TLS에 대한 포스팅이 아니기 때문에 이 이상의 설명은 추후 포스팅에서 다룬다.

 

본론으로 돌아와서, HTTPS에 S가 붙은 것은 TLS가 적용된 HTTP를 뜻하는 것이다.

그래서 HTTPS가 적용된 사이트, HTTP가 적용된 사이트의 주소창 맨 왼쪽을 확인해보면 자물쇠가 있는데, 이걸 클릭해보면 HTTPS 적용 여부를 확인할 수 있다.

 

 

이 화면은 글을 작성하는 지금 티스토리 화면에서 확인한 내용이다. 이걸로 티스토리는 HTTPS를 사용하고 있다는 걸 알 수 있다.

그럼 이 HTTPS는 왜 쓰는 것일까? HTTP가 뭔가 모자라니까 이걸 보충해서 나온 것이 HTTPS일 것이다.

 

HTTP의 단점은 아래와 같다.

 

• HTTP에서 사용되는 암호화 방법이 없다. 그래서 누가 데이터를 바꿀 수 있다.
• 암호화가 안 돼 있으니 클라이언트와 서버 간 통신 시 해커가 중간에 데이터를 가로챌 수 있다.

2개지만 내가 당한다고 생각하면 하나같이 무서운 단점이다.

그래서 HTTP에 TLS를 적용시키고, 안전하다는 S를 붙여서 HTTPS가 나온 것이다.

이 HTTPS 적용 여부를 확인하려면 위에서 말했듯 새로고침과 주소창 사이에 있는 공간을 확인해보면 알 수 있다.

 

 

결론

• HTTP란 클라이언트와 서버 간 데이터 전송(≒통신)에 사용되는 규칙이다
• HTTP는 데이터를 암호화하지 않아서 중간에 해커가 데이터를 가로챌 수 있다는 단점이 있다. 그래서 이걸 보완하고자 TLS라는 암호화 프로토콜을 적용해서 보안을 강화한 HTTP가 나왔다. 이것이 HTTPS다
• TLS는 SSL이라는 암호화 프로토콜의 진보된 버전이다
• 프로토콜은 신호를 보내는 순서, 데이터 표현법 등을 정한 것으로, 데이터 통신 시 지켜야 할 규칙이다.