[Network] HTTP와 HTTPS

✔️ HTTP와 HTTPS

HTTP란?

• HyperText Transfer Protocol
• 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
• 클라이언트가 브라우저를 통해 URI로 특정 요청을 보내면 서버는 해당 요청을 받아 처리하여 클라이언트에게 응답
• 비연결을 지향하고 단방향성을 가짐
• HTTP는 텍스트 교환이므로 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재
• 그 외에도 완전성을 증명할 수 없기 때문에 변조와 위장이 가능함
• 이를 해결하기 위해 쿠키, 세션, 히든 폼 필드 등을 사용

HTTP 헤더

• HTTP 헤더 내 일반 헤더 항목 : 요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의 헤더 항목
  1. Date : HTTP 메시지를 생성한 일시
  2. Connection : 클라이언트와 서버 간 연결에 대한 옵션 설정
  3. Cache-Control
  4. Pragma
  5. Trailer
• HTTP 헤더 내 엔터티 헤더 항목 : 요청 및 응답 메시지 모두에서 사용 가능한 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명 헤더
  1. Content-Type : 해당 개체에 포함되는 미디어 타입 정보
  2. Content-Language : 해당 개체와 가장 잘 어울리는 사용자 언어
  3. Content-Encoding : 해당 개체 데이터의 압축 방식
  4. Content-Length : 전달되는 해당 개체의 바이트 길이 또는 크기
  5. Content-Location : 해당 개체가 실제 어디에 위치하는가
  6. Content-Disposition : 응답 Body를 브라우저가 어떻게 표시해야 할지 알려주는 헤더
  7. Content-Security-Policy : 다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 명시
  8. Location : 리소스가 리다이렉트된 때에 이동된 주소, 또는 새로 생성된 리소스 주소
  9. Last-Modified : 리소스를 마지막으로 갱신한 일시
• HTTP 헤더 내 요청 헤더 항목 : HTTP 요청 메시지 내에서 나타나는 헤더 항목
  1. Host : 요청하는 호스트에 대한 호스트명 및 포트번호
  2. User-Agent : 클라이언트 소프트웨어 명칭 및 버전 정보
  3. From : 클라이언트 사용자 메일 주소
  4. Cookie : 클라이언트에게 설정된 쿠키 정보
  5. Referer : 바로 직전에 머물렀던 웹 링크 주소
  6. If-Modified-Since : 제시한 일시 이후로만 변경된 리소스를 취득 요청
  7. Authorization : 인증 토큰을 서버로 보낼 때 사용하는 헤더
  8. Origin : POST 요청을 보낼 때, 요청이 어디에서 시작되었는지 나타내며 요청 주소와 받는 주소가 다르면 CORS 에러 발생
• HTTP 헤더 내 응답 헤더 항목 : 특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때의 헤더 항목
  1. Server : 서버 소프트웨어 정보
  2. Accept-Range 
  3. Set-Cookie : 서버측에서 클라이언트에게 세션 쿠키 정보를 설정
  4. Expires : 리소스가 지정된 일시까지 캐시로써 유효함
  5. Age : 캐시 응답 max-age 시간 내에서 얼마나 흘렀는지
  6. ETag : HTTP 컨텐츠가 바뀌었는지 검사할 수 있는 태그
  7. Proxy-authenticate 
  8. Allow : 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트
  9. Access-Control-Allo-Origin : 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생

HTTP 메서드

1. GET : URI가 가진 정보를 검색하기 위해 요청하는 메소드
   • 정보를 조회하기 위한 메소드로 서버에서 어떤 데이터를 가져와서 보여주기 위한 용도 (SELECT)
   • URL의 끝에 '?'가 붙고 요청 정보가 Key, Value 형태의 쌍을 이루어 ? 뒤에 이어서 붙어 서버로 전송됨
   • 요청 정보가 여러 개일 경우네는 '&'로 구분함
   • URL에 요청 정보가 이어붙기 때문에 길이 제한(255자)이 있어 대용량의 데이터를 전송하기 어려우며
     요청 정보를 사용자가 쉽게 눈으로 볼 수 있는 만큼 보안상 취약하지만 빠름
2. HEAD : GET 메소드와 방식은 동일하지만, 응답에 Body가 없고 응답 코드와 HEAD만 응답하는데 사용되는 메소드
3. POST : 요청된 자원을 생성하기 위한 메소드
   • 서버의 값이나 상태 정보를 바꾸기 위한 용도 (INSERT, UPDATE, DELETE)
   • 요청 정보를 인코딩하여 HTTP 패킷의 Body 안에 숨겨서 서버로 전송하고, 서버 족에서 해당 데이터를 디코딩하게 됨
   • Request Header의 Content-Type에 해당 데이터 타입이 표현될 수 있음
   • 대용량의 데이터를 전송하기 적합하며 보안상 안전함
4. PUT : 요청된 자원을 수정할 때 사용하고, PATCH와 다르게 자원 전체를 갱신하는데 사용되는 메소드
5. PATCH : PUT 메소드와 유사하게 요청된 자원을 수정할 때 사용되지만, 자원의 일부를 수정하는 의미로 사용되는 메소드
6. DELETE : 요청된 자원을 삭제하기 위한 메소드
7. CONNECT : 동적으로 터널 모드를 교환하고 프록시 기능을 요청할 때 사용하는 메소드
8. TRACE : 원격 서버에 로프백 메세지를 호출하기 위해 테스트 용도로 사용하는 메소드
9. OPTIONS : 웹 서버에서 지원하는 메소드 종료들을 확인할 경우 사용하는 메소드

HTTP 상태 코드

• 정보 전송 임시 응답 (1xx) : 서버가 요청을 클라이언트에게 성공적으로 수신을 했고 서버에서 처리중인 정보를 보냄
  
  1. 100 : Continue
  2. 101 : Switching protocols
• 성공 (2xx) : 서버가 요청을 성공적으로 받았음
  1. 200 : Ok
  2. 201 : Created
  3. 202 : Accepted
  4. 203 : Non-authoritative Information
  5. 204 : No content
• 리다이렉션 (3xx) : 캐싱된 파일을 새로고침하여 확인
  1. 301 : Moved permanently
  2. 302 : Not temporarily
  3. 303 : Not modified
• 클라이언트 요청 오류 (4xx) : 클라이언트에서 서버에 잘못된 요청을 보내 서버가 요청을 해결 할 수 없을 때 발생
  1. 400 : Bad Request
  2. 401 : Unauthorized
  3. 402 : Payment required
  4. 403 : Forbidden 
  5. 404 : Not found
  6. 405 : Method not allowed
  7. 407 : Proxy authentication required
  8. 408 : Request timeout
  9. 410 : Gone
  10. 412 : Precondition failed
  11. 414 : Request-URI too long
• 서버 에러 (5xx) : 클라이언트의 요청을 받고 서버에서 처리하지 못할 때 발생
  1. 500 : Internal server error
  2. 501 : Not implemented
  3. 503 : Service unavailable
  4. 504 : Gateway timeout 
  5. 505 : HTTP version not supported

HTTS란?

• HyperText Transfer Protocol Secure
• HTTP의 보안 문제를 해결해주는 프로토콜로
  인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 사용하는 통신 규약
• 텍스트를 공개키 암호화 방식으로 암호화하게 됨
• HTTP와 달리 상대를 확인하는 수단으로 증명서를 제공하므로 통신 상대를 확인할 수 있고,
  해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재해 완전성을 보장하고자 함
• 모든 웹페이지에서 HTTPS를 사용할 경우 CPU나 메모리 등 리소스를 많이 필요로 하므로
  민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용
• 하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며,
  새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작하므로
  웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서
  현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있음

HTTP 동작 과정

1. 사용자가 웹 브라우저에 URL 주소 입력
2. DNS 서버에 웹 서버의 호스트 이름을 IP 주소로 변경 요청
3. 3way-handshaking을 통해 웹 서버와 TCP 연결 시도
4. 클라이언트가 HTTP Request Message(Request Header + 빈 줄 + Reqeust Body)로 서버에게 요청
5. 서버가 클라이언트에게 HTTP Response Message(Response Header + 빈 줄 + Response Body)로 데이터 응답
6. 4way-handshaking을 통해 서버와 클라이언트 간 연결 종료
7. 웹 브라우저가 웹 문서 출력

HTTS 동작 과정 (TLS/SSL handshake)

• 통신 자체를 암호화 TLS (Transport Layer Security)/SSL (Secure Socket Layer) 프로토콜과 조합하여 암호화
• HTTPS에서 클라이언트와 서버간 통신 전 SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식
  1. 클라이언트는 서버에게 client hello 메시지를 담아 서버로 보냄
     이때 암호화된 정보(버전, 암호 알고리즘, 압축 방식 등)를 함께 담음
  2. 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고, 
     세션 ID와 CA 공개 인증서를 server hello 메시지와 함께 담아 응답
     이 CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전,
     클라이언트에서 handshake 과정 속 암호화에 사용할 공개키를 담고 있음
  3. 클라이언트 측은 서버에서 보낸 CA 인증서에 대해 유효한 지 CA 목록에서 확인하는 과정을 진행
  4. CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 난수 바이트를 생성하여 서버의 공개키로 암호화
     이 난수 바이트는 대칭키를 정하는데 사용이 되고, 앞으로 서로 메시지를 통신할 때 암호화하는데 사용
  5. 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면,
     클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보냄
  6. 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용
  7. 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서,
     지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내줌
  8. 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인
     일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보냄
  9. 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고,
     앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고받을 수 있게 됨