HTTP vs HTTPS
한마디 버전: 한국어 : HTTP는 Hypertext Transfer Protocol의 약자로 HTML 문서와 같은 리소스들을 가져올때 사용하는 프로토콜입니다. HTTP 프로토콜은 모든 데이터 교환의 기초 이며, 다른 말로는 클라이언트-서버 프로토콜이라고 합니다. HTTPS는 SSL 보호막을 두른 HTTP 입니다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) 이나 TLS(Transport Layer Security)라는 프로토콜로 대체합니다. 영어 : HTTP stands for Hypertext Transfer Protocol, which is the protocol to collect resources such as HTML documents. HTTP protocol is the basis for all data exchanges, otherwise known as client-server protocol. HTTPS is HTTP with an SSL shield. HTTPS is just replacing the socket that HTTP communicates with another protocol called Secure Socket Layer (SSL) or Transport Layer Security (TLS). |
1. HTTP의 버전(역사)
HTTP에도 버전이 있고 역사가 있습니다. 사실 제가 예전에 면접 준비하면서 만들어 둔 영문 스크립트도 있고 해서 HTTP vs HTTPS를 본격적으로 하기 전에 여기에 올릴려고 합니다.
HTTP/0.9
초기 버전의 HTTP는 원래 버전 정보가 없었고 나중에 이 버전이 0.9가 되었습니다. HTTP 헤더 없이 매우 간단한 GET 통신이 가능하므로 전송은 HTML 문서에서만 가능하며 다른 유형은 전송할 수 없습니다. 또한 상태나 오류 코드가 없기 때문에 문제 설명을 포함하여 파일 내부에 문제가 전송되었습니다.
HTTP/1.0
HTTP/1.0에서는 응답 시작 시에 상태 코드가 포함되었으므로 이제 요청이 성공하여 즉시 실패했음을 알 수 있습니다. 또한 위에서 언급한 HTTP 헤더가 요청과 응답 모두에 추가되어 프로토콜의 유효성을 확인할 수 있었고, Content-Type 헤더의 도움을 받아 다른 비 HTML 파일을 전송할 수 있었습니다. Method POST, HEAD도 추가되었습니다.
헤더 추가: Content-Type, Authorization, User-Agent
HTTP/1.1
HTTP/1.1은 HTTP의 첫 번째 표준 버전입니다. Method 로는 OPTIONS, PUT, DELETE 및 TRACE가 추가되었고, 몇 가지 헤더(Via 및 Accept)가 추가 되었습니다.
또한 HTTP/1.1에서는 성능을 개선하기 위해 몇 가지 변경 사항이 적용되었습니다. 예를 들어 이전 HTTP/1.0 통신에서는 동일한 클라이언트와 동일한 서버가 10개의 연결, 10개의 요청 및 응답, 10개의 요청을 하려면 10개의 연결을 끊어야 했습니다. 그러나 HTTP/1.1은 연결 정보를 일정 기간 동안 기억하므로 빈번한 연결 및 연결해제을 줄입니다.
같은 이유로 Pipelining이 추가되었습니다.
HTTP/2.0
HTTP/1.1까지는 http가 텍스트 프로토콜이었지만, HTTP/2.0은 이진 프로토콜입니다. 이제 HTTP/2.0에 스트림이 있으므로 연결하거나 연결을 끊을 필요가 없습니다. 헤더 압축(HTTP/2.0)에서는 HPACK를 사용하여 모든 헤더가 압축 및 인덱싱됩니다. 빠른 로딩을 위하여 이미지 파일등을 작게 자를 필요가 없습니다. 지금은 HTTP/2.0과 HTTP/1.1이 주로사용 됩니다.
영어 버전은 첨부파일로 올려드리겠습니다.
2. HTTP vs HTTPS
HTTP의 약점
- 도청 및 누구나 통신되는 내용을 들여다 볼수 있습니다.(HTTP 는 평문 통신).
- HTTP 통신은 통신상대가 누군지 모릅니다.
- 쉽게 위변조가 가능합니다.
도청가능!
비단 HTTP 프로토콜 뿐아니라 암호화 되지 않은 프로토콜은 누구나 도청 당할 수 있습니다. TCP/IP 가 도청이 가능한 네트워크 이기 때문인데요. 서울에서 부산가는 길에 서 있으면 어떤 차가 지나가는지 볼 수 있지요. 그 경로 상에서 패킷을 수집하는 것만으로 도청이 가능합니다.
이 것을 보안하는 방법이 HTTPS를 사용하는 것인데요. HTTP 메세지에 포함되는 내용만 암호화 하여 SSL이나 TLS 프로토콜을 조합해 전송할 수 있습니다. 물론, 전송받은 상대는 암호를 해독해야 합니다. HTTPS를 우리는 HTTP Secure 또는 HTTP over SSL 이라고 합니다.
넌 누구냐!
HTTP로 통신하는 동안은 내가 누군지 밝히고 처리하지 않기 때문에 누구든 어디든, 물리적으로 방화벽에 막혀 있지 않는 이상, 요청이 오면 항상 반응합니다. 반응성은 좋은데.. 문제가 많습니다.
- 아무 요청에 다 반응하니 디도스 공격등에서 자유로울수 없습니다.
- 내가 요청을 보는 서버가 진짜 내가 의도한 요청 타겟이 맞는지?
- 내가 받은 응답이 진짜 내가 요청보낸 타겟에서 온 응답이 맞는지?
- 웹서버 입장에서는, 대체 누가 요청한 것인지?
위변조!
서버는 그리고 클라이언트는 서로 받는 요청과 응답이 HTTP 상에서 정확하고 위변조가 되지 않았는지 확인할 길이 없습니다. 중간에 오는 길에 변조할 수 있기 때문이지요. 중간에서 지속적으로 변조하고 있으면 서버와 클라이언트는 이를 서로 알길이 없습니다. 이건 공격법이 중간자(Man-in-the-middle) 공격이라고 하는데, SSL 구현으로 보완할 수 있습니다. 물론, HTTPS를 사용하지 않고도 해시 데이터를 서로 주고 받는 방법으로 할수 있지만, 확실하게 하려면 HTTPS를 사용 하면 됩니다.
완전성을 증명할 수 없기 때문에 변조가 가능하다
여기서 완전성이란 정보의 정확성 을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.
3. HTTP vs HTTPS 속도
상식적으로 생각해도 HTTP가 더 빠를 것이라 생각됩니다. 왜냐하면 암호화하고 다시 해독하는 작업이 있기 때문이지요. 때문에 CPU등 리소스도 더 많이 필요하여, HTTP의 초당 처리건수가 더 많은 것이 사실 입니다.
근데 안할 수 가 없습니다.
HTTPS 사이트에서 HTTP를 호출하면 검색엔진에서 유해사이트로 분류해 검색이 안됩니다..
HTTP 사이트에서 HTTPS를 호출 할 순 있지만, 브라우저별로 다르겠지만 크롬의 경우 '이 사이트에 대한 연결은 안전하지 않습니다' 라는 메세지가 뜹니다.
그리고, 일부만 HTTPS로 암호화 한다고 해도 중간자 공격을 하는 입장에서는 이것 저것 암호화 되지 않은 정보로 여러 힌트를 얻어 다른 공격을 진행 할수 있습니다. 그래서 일부만 암호화 통신을 하는 것도 안전하지 않습니다.
4. 그럼 느리게 써야 하나요?
아니에요.
HTTP/2.0 이 발전되면서 HTTPS 가 HTTP 보다 빨라졌습니다.
이 글 도 한번 읽어 보세요 : HTTPS 가 HTTP 보다 빠르다.
아 그리고 몸소 체험하고 싶으신가요?
여기서 체험하실수 있습니다.
