6. HTTP, HTTPS
HTTP
Hyper Text Transfer Protocol, WWW상에서 HTML 문서와 같은 리소스들을 주고 받기 위한 통신 규약이다. 웹에서 이루어지는 모든 데이터 교환의 기초이며, 서버와 클라이언트에서 요청, 응답 프로토콜을 통해 정보를 주고 받을 수 있다.
HTTP 특징
비연결 지향
일반적으로 클라이언트가 서버에게 자원을 요청한 후, 응답을 받고 서버측에서 연결을 끊는다. 많은 클라이언트와 연결이 지속되어 발생하는 서버의 부하를 막기 위함이다.
무상태성
각각의 요청을 독립적으로 보는 특성이다. 즉, 서버는 클라이언트의 상태를 유지하지 않고 서버의 자원을 제공하기 때문에 클라이언트의 상태에 맞는 자원 제공이 불가능하다. 이러한 특징을 보완하기 위한 방법으로는 쿠키와 세션을 사용할 수 있다.
HTTP 메세지
HTTP 메세지는 서버와 클라이언트 간 데이터 교환 방식이다. 메세지는 ASCII로 인코딩된 텍스트 정보로 구성되어 있으며, 개발자가 손수 작성하기 보단 브라우저 혹은 웹 서버가 대신 작성하는 것이 일반적이다. 하지만, 그 구조는 이해하고 읽을 줄 알아야 한다.
요청 메세지, 서버에 액션을 발생시키는 메세지 (라인, 해더, 바디)
라인, 요청 메세지의 첫째 줄은 라인으로 불리며 메세지를 발행한 HTTP 메서드, 자원의 URL, HTTP 버전 정보를 담고 있다.
해더, 요청 메세지 해더에 들어가는 정보는 요청에 대한 속성과 조건을 나타내는 곳으로 키와 값의 쌍으로 구성되어 있다.
바디, 메세지의 본문이 들어간다. 모든 요청에 들어가지 않고 해당 요청에 필요한 파라미터를 담아 서버로 전달하는 데 사용한다.
name=yu&age=27 응답 메세지, 요청에 대한 서버의 답변을 전달하는 메세지
라인, HTTP 버전, 응답에 대한 상태 코드, 상태 코드에 대한 간단한 설명이 포함되어 있다.
해더, 응답에 대한 속성과 조건을 나타내는 곳으로 키와 값의 쌍으로 구성되어 있다.
HTTP 주요 해더
약속된 키와 값의 쌍을 통해 요청, 응답의 속성과 조건을 담을 수 있다.
요청 해더
Host, 서버의 도메인 네임과 TCP 포트번호를 명시한다. 즉, 요청의 주체가 되는 호스트
User-Agent, 요청을 보낸 클라이언트의 정보. 브라우저, 운영체제, 기기의 정보 등이 담겨 클라이언트의 기기를 식별할 때 사용 가능하다.
Accept, 요청시 응답으로 전달받을 데이터의 기대 형식을 서버에 전달하기 위해 명시한다. Accept-Encoding, Accept-Charset, Accept-Language 등
Authorization, 서버측에서 클라이언트의 인증 정보를 요구하는 경우 토큰과 같은 키값을 명시한다. 제공하지 않은 경우, 401 반환.
Origin, 요청이 시작된 해당 주소를 명시한다. 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러를 브라우저에서 발생시킨다.
Referer, 현재 요청을 보낸 페이지의 주소를 명시한다. a.com에서 b.com을 요청하여 이동했을때 a.com이 referer에 담긴다. 해당 클라이언트가 어디서 유입되었는지 확인하는데 사용할 수 있고, CSRF 공격 방어에도 사용할 수 있다.
Origin은 메인 도메인 (a.com), Referer은 완결된 경로까지 포함한다. (a.com/index.html)
If-Modified-Since, 명시되어 있는 날짜 이후에 갱신된 자원만을 획득하고자 하는 경우 명시한다.
응답 해더
Access-Control-Allow-Origin, 요청을 허가하는 오리진 도메인을 명시한다. 요청 해더에 담긴 Origin과 동일하지 않으면(프로토콜, 호스트, 포트번호가 모두 일치해야 한다.) CORS 에러가 발생한다. 일반적으로 CORS 에러를 해결하기 위해 서버측에서 명시한다.
Allow, 서버에서 허가하는 요청 메서드를 나열하여 명시한다. 명시되어 있는 메서드가 아닌 경우, 405 (Method Not Allowed)
Location, Redirect를 요구하는 300번대 상태 코드에 대해 어느 곳으로 이동되어야 하는지 명시한다.
Content-Security-Policy, 외부 파일들을 불러오는 경우 차단 혹은 불러올 소스를 구분지어 명시한다. 가령, 허용 목록에 있는 도메인에서 수신한 스크립트만 실행하고, 그 외 스크립트의 실행을 무시할 수 있다. 크로스 스크립팅(XSS) 위험성을 제거한다.
공통 해더
Date: HTTP 메세지가 작성된 시각을 명시한다.
Connection, 서버와 클라이언트의 연결 지속성을 명시한다. 비연결을 지향하는 HTTP에 따라 매번 연결이 끊기게 되는데 keep-alive 값을 전달하여 서버측에게 연결을 지속하기를 원한다는 의사 전달. HTTP 1.1 부터는 keep-alive가 기본값이며 close를 전달할 경우 연결 종료.
Content-Type, 요청의 경우 POST, PUT 메서드를 통한 요청에 대한 요청 바디에 담긴 정보들의 타입을 명시할 수 있고, 서버측의 경우 응답 데이터의 타입을 명시한다. 응답 데이터의 타입을 보고 브라우저는 랜더링 혹은 다운로드와 같은 데이터 수용 방식을 결정한다.
Content-Encoding, 컨텐츠의 압축방식을 명시한다. 요청의 경우 브라우저에서 사용할 수 있는 압축 방식을 나열하고, 서버측에서 해당 데이터에 적합한 압축방식으로 압축을 진행하고 해당 압축 방식을 명시한다.
Content-Length, 요청, 응답 메세지의 본문 크기를 바이트 단위로 명시한다.
Cache-Control, 브라우저 캐싱에 사용되는 해더
HTTP 메서드
GET, 서버의 데이터를 READ
POST, 서버에 데이터를 CREATE
PUT, 서버의 데이터를 UPDATE (파일 전송 혹은 자원의 모든 필드값을 수정할 경우)
PATCH, 서버의 데이터를 UPDATE (자원의 일부 필드값을 수정할 경우)
HEAD, 메세지 해더를 READ
DELETE, 서버의 데이터를 DELETE
OPTIONS, 서버에서 지원하고 있는 메서드를 READ
HTTP 상태 코드
200번대, 요청 정상 처리
200 OK, 정상 처리
201 Created, 요청한 자원 생성이 정상 처리
204 No Content, 정상 처리되었지만, 반환할 데이터가 없음
206, Partial Content, 부분적으로 GET 요청을 받았으며, 해당 요청 정상 처리
300번대, 요청 정상 처리를 위해 클라이언트 측에서 후수 처리 필요
301 Moved Permanently, 요청한 자원에 새로운 식별자가 할당되어, 리소스 참조를 위해 새로운 식별자를 사용하도록 요구
302 Found, 요청한 자원이 새로운 URI가 할당되어 새로운 URI를 사용하도록 요구
304 Not Modified, 요청 메서드에 If-Modified-Since가 포함되어 있는 경우, 요청한 자원이 수정 사항이 없어 다시 자원을 보낼 필요가 없음
400번대, 요청 처리에 문제가 발생했으며 문제 발생 원인이 클라이언트에 있음
400 Bad Request, 요청 구문이 잘못되어 요구하지 않았거나 요구된 구문이 없는 경우 처리할 수 없거나, 처리하지 않겠음
401 Unathorized, 요청한 자원의 접근을 거부, 요청 해더에 Authorization이 없거나, 해당 값이 만료 혹은 적절하지 않을때 거절하겠음
401 Forbidden, 요청한 자원에 대한 접근을 거부, 클라이언트가 해당 자원에 대한 읽고, 수정할 권한이 없을 때 거절하겠음
404 Not Found, 요청한 자원이 없을때
405 Method Not Allowed, 요청에 사용된 메서드에 대해 발생한 액션이 해당 자원에 적절하지 않을때 거절하겠음
500번대, 요청 처리에 문제가 발생했으며 문제 발생 원인이 서버에 있음
500 Internal Server Error, 서버에서 요청을 처리하는 과정에 알 수 없는 에러가 발생했음을 공유
501 Service Unavailable, 일시적인 서버의 과부하 혹은 점검 중임을 공유
HTTP 보안상의 문제점
HTTP의 경우 평문으로 요청과 응답을 주고 받기 때문에 노출되거나, 중간에 가로채 의도치 않은 응답으로 변경될 수 있다. 하지만, 응답을 받은 클라이언트는 응답 변조 여부에 대해 판단하기 어렵다.
HTTPS
HTTPS는 평문 텍스트로 통신되는 HTTP의 보안상의 문제를 해결하기 위해 도입된 프로토콜로, Over Secure Socket Layer 라는 개념을 도입하여 보안이 강화되었다.
SSL
HTTP는 응용 계층에서 사용되는 프로토콜이지만, HTTP를 표현계층에서 사용되는 SSL(Secure Socket Layer)로 덮어쓴 것이 HTTPS이다. 즉 HTTP를 통신하는 소켓 부분을 SSL 프로토콜로 대체하여 사용하는 것
TLS
SSL는 네스케이프에 의해 발명되었고, 점차 널리 사용되다가 표준화 기구 IETF 관리로 변경되면서 TLS라는 이름으로 변경되었다. 즉, SSL, TLS는 동일. 마찬가지로, 기존 HTTP 통신의 동작에 TLS를 사용한 TLS Handshake 확인 과정이 추가된다.
공개키와 비밀키
누구나 볼 수 있는 공개키, 소유자만 알 수 있는 키다. 공개 키로 암호화된 정보를 비밀키로 복호화하는 구조.
대칭키
하나의 키를 통해 서버와 클라이언트가 암호화, 복호화를 진행한다. 키를 공유하는데 어려움이 있으나, 이후 암호화, 복호화 과정의 속도가 빠르다.
인증기관 (CA)
클라이언트가 접속한 서버가 의도한 서버가 맞는지 제 3자로서 보증해주는 기관들.
HTTPS TLS 인증 과정
Client Hello, TCP handshake를 통해 연결이 되었다면, 브라우저는 서버측으로 SSL버전 정보, 브라우저가 지원하는 암호화 방식, 생성한 임의의 난수 등을 전송한다.
Server Hello, Client Hello 패킷에 담긴 암호화 알고리즘 중 서버가 선택한 암호화 알고리즘을 통보한다.
Certificate,
서버는 공개키가 담긴 제 3자로부터 전달받은 암호화된 SSL 인증서를 클라이언트에 제공한다.
클라이언트는 제 3자 인증기관으로부터 전달받아 소유하고 있는 공개키를 통해 이를 복호화한다.
클라이언트가 복호화에 성공할 경우 인증 기관에서 서명한 것이 맞다는 것이 입증이 됨. 이후 연결 과정을 진행.
Client Key Exchange, 클라이언트는 자신이 생성한 난수, 서버로부터 전달받은 난수를 사용하여 데이터를 주고 받을 때 사용할 대칭키를 생성하고, SSL 인증서에 담겨 있었던 공개키를 통해 이를 암호화하여 전달하고, 서버는 공개키에 대응되는 비밀키를 통해 대칭키를 복호화한다.
Client Finished, 클라이언트는 서버에게 자신의 역할이 모두 마무리되었고, 통신 준비가 완료되었음을 알리기 위해 Finished 패킷을 전달한다.
Server Finished, 서버는 자신도 역할이 마무리되었고, 통신 준비가 완료되었음을 알리기 위해 Finished 패킷을 전달한다.
Exchange Message, 서버, 클라이언트 모두 대칭키를 통해 데이터를 암호화하여 전송, 복호화하는데 사용한다. 이후 세션이 종료되면 대칭키를 파괴한다. 이때 데이터는 대칭키를 통해 모든 데이터 및 메세지 내용을 암호화한다.
Last updated