HTTP와 HTTPS

HTTP

• Hyper Text Transfer Protocol
• 웹 상에서 클라이언트와 서버 간에 request/response로 정보를 주고 받을 수 있는 프로토콜
• TCP/UDP를 사용하며, 80번 포트 사용.

HTTPS

• Hyper Text Transfer Protocol over Secure Socket Layer
• 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전의 프로토콜
• TCP/IP의 포트로 443번 포트 사용.
• 네트워크 상에서 열람, 수정이 불가능하므로 안전하다.
• 암호화를 하는 과정이 웹 서버에 부하를 준다.
• HTTPS는 설치 및 인증서를 유지하는데 추가 비용이 발생한다.
• HTTP에 비해 느리다.

HTTPS가 필요한 이유

• 클라이언트인 웹 브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공. 이때 웹 페이지(HTML)는 텍스트이고, HTTP를 통해 이런 텍스트 정보를 교환하는 것이다.
• 주고받는 텍스트 정보에 주민등록번호나 비밀번호와 같이 민감한 정보가 포함된 상태에서 네트워크 상에서 중간에 제3자가 정보를 가로챈다면 보안상 큰 문제가 발생한다.
• 즉, 중간에서 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용하는 것이다.

HTTPS 동작 방법

• 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
• 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.

  CA란? : Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업
  계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.

• A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
• 클라이언트는 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
• CA 기업의 공개키는 브라우저가 이미 알고있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)
• 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다. 이제 A서버와 통신할 대는 얻은 A서버의 공개키로 암호화해서 요청을 날리게 된다.
• HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서 발급한 경우 등)
• 이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

HTTP 헤더

General Header

• request, response에서 모두 사용 가능한 일반 목적의 헤더.

주요 항목들

• Date: HTTP 메시지를 생성한 일시 (RFC 1123에서 규정)
• Connection: 클라이언트와 서버 간 연결에 대한 옵션 설정(다소 모호한 복잡성 있음)
  • Connection: close, 현재 HTTP 메시지 직후에 TCP 접속을 끊는다는 것을 알림
  • Connection: Keep-Alive, 현재 TCP 커넥션을 유지
• Cache-Control: 브라우저가 관리하는 캐시 관리, 보통 GET 요청에만 사용.
  • Cache-Control: no-store, 아무것도 캐싱하지 않음.
  • Cache-Control: no-cache, 모든 캐시를 사용하기 전에 서버에 판단을 요청.
  • Cache-Control: must-revalidate, 만료된 캐시만 서버에 판단을 요청.
• Pragma: HTTP/1.1 버전의 Cache-Control 헤더가 생기기 전 그것과 동일한 역할을 하는 대용 헤더.
• Trailer: Trailer 헤더는 수신자로 하여금 어떠한 HTTP 헤더가 Chunked 방식의 트레일러로 사용될 것인지를 알게 해주는 헤더

Entity Header

• request, response에서 모두 사용 가능한 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명 헤더.

주요 항목들

• Content-Type: 해당 개체에 포함되는 미디어 타입 정보
  • 컨텐츠의 타입(MIME 미디어 타입) 및 문자 인코딩 방식(EUC-KR,UTF-8 등)을 지정
  • 타입 및 서브타입(type/subtype)으로 구성
  • Content-Type: text/html; charset-latin-1 => 해당 개체가 html으로 표현된 텍스트 문서이고, iso-latin-1 문자 인코딩 방식으로 표현됨
• Content-Language: 해당 개체와 가장 잘 어울리는 사용자 언어(자연언어)
• Content-Encoding: 해당 개체 데이터의 압축 방식
  • Content-Encoding: gzip, deflate
  • 만일 압축이 시행되었다면, Content-Encoding 및 Content-Length 2개 항목을 토대로 압축 해제 가능
• Content-Length: 전달되는 해당 개체의 바이트 길이 또는 크기(10진수)
  • 응답 메시지 Body의 길이를 지정하거나, 특정 지정된 개체의 길이를 지정함
• Content-Location: 해당 개체가 실제 어디에 위치하는가를 알려줌
• Content-Disposition: 응답 Body를 브라우저가 어떻게 표시해야 할지 알려주는 헤더
  • inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드
  • Content-Disposition: inline
  • Content-Disposition: attachment; filename='filename.csv'
  • 다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다.
  • 파일용 서버인 경우 이 태그를 자주 사용
• Content-Security-Policy: 다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 명시
  • XSS 공격에 대한 방어 가능 (허용한 외부 소스만 지정 가능)
  • Content-Security-Policy: default-src https;://example.com, https를 통해서만 파일을 가져옴
  • Content-Security-Policy: default-src 'self', 자신의 도메인의 파일들만 가져옴
  • Content-Security-Policy: default-src 'none', 파일을 가져올 수 없음
• Location: 리소스가 리다이렉트(redirect)된 때에 이동된 주소, 또는 새로 생성된 리소스 주소
  • 300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려주는 헤더
  • 새로 생성된 경우에 HTTP 상태 코드 201 Created가 반환됨
  • HTTP/1.1 302 Found Location: /
    • 이런 응답이 왔다면 브라우저는 / 주소로 redirect한다.
• Last-Modified: 리소스를 마지막으로 갱신한 일시

Request Header

• 요청 헤더는 HTTP 요청 메시지 내에서만 나타나며 가장 방대함.

주요 항목들

• Host: 요청하는 호스트에 대한 호스트명 및 포트번호 (필수)
  • Host 필드에 도메인명 및 호스트명 모두를 포함한 전체 URI(FQDN) 지정 필요
  • 이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트가 구축 가능
• User-Agent: 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보
• From: 클라이언트 사용자 메일 주소
  • 주로 검색엔진 웹 로봇의 연락처 메일 주소를 나타냄
  • 때로는, 이 연락처 메일 주소를 User-Agent 항목에 두는 경우도 있음
• Cookie: 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
• Referer: 바로 직전에 머물었던 웹 링크 주소
• If-Modified-Since: 제시한 일시 이후로만 변경된 리소스를 취득 요청
• Authorization: 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더
  • 토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자를 전송
• Origin
  • 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄
  • 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
  • 응답 헤더의 Access-Control-Allow-Origin와 관련
• 다음 4개는 주로 HTTP 메세지 Body의 속성 또는 내용 협상용 항목들
  • Accept: 클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알림
    • Accept: / => 어떤 미디어 타입도 가능
    • Accept: image/* => 모든 이미지 유형
• Accept-Charset: 클라이언트 자신이 원하는 문자 집합
• Accept-Encoding: 클라이언트 자신이 원하는 문자 인코딩 방식
• Accept-Language: 클라이언트 자신이 원하는 가능한 언어
• 각각이 HTTP Entity Header 항목 중에 Content-Type, Content-Type charset-xxx, Content-Encoding, Content-Language과 일대일로 대응됨

Response Header

• 특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때, 이에 응답하는 헤더.

주요 항목들

• Server: 서버 소프트웨어 정보
• Accept-Range
• Set-Cookie: 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)
• Expires: 리소스가 지정된 일시까지 캐시로써 유효함
• Age: 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 알려줌(초 단위)
• ETag: HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
• Proxy-authenticate
• Allow: 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타냄
  • 때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목
    • OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의
  • Allow: GET,HEAD => 웹 서버측이 제공 가능한 HTTP 메서드는 GET,HEAD 뿐임을 알림 (405 Method Not Allowed 에러와 함께)
• Access-Control-Allow-Origin: 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
  • 서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
  • Access-Control-Allow-Origin: www.example.com
    • 프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
  • Access-Control-Allow-Origin: *
    • 만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
    • 유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.

Reference

• Http와 Https 이해와 차이점 그리고 오해(?)