[Network] 2.HTTP, HTTPS

1. HTTP(HyperText Transfer Protocol)

 HTTP는 분산 하이퍼 미디어 환경에서 빠르고 간편하게 데이터를 전송하는 프로토콜로 서로 다른 체계의 시스템 사이에서 통신을 주고 받는 가장 기초적인 프로토콜이다. 

 HTTP 메소드를 이용해 클라이언트가 서버에 데이터를 전송하고,  서버가 클라이언트로 데이터를 회신 할 수 있다. 대표적으로 클라이언트가 정보를 요청할 때는 GET, 서버에 메시지를 전달할 때(회신할때)는  POST메서드를 사용하여 통신한다.

 

1) 특징

HTTP의 통신은 다음과 같이 이루어 진다.

HTTP 통신은 다음과 같은 특성을 띈다.

 

• 통신방법
  • HTTP는 기본적으로 TCP를 이용하여 통신을 진행한다.
  • 서버와 클라이언트에 의해 해석된다.
  • TCP/IP를 이용하는 응용프로토콜이다.
  • 요청 - 응답 방식으로 동작한다.
  • 도메인+URL/URI 를 통해 요청을 하고 이에 따라 서버가 HTML 문서를 응답해 준다.
  • 요청 - 응답 프로세스가 끝나면 TCP연결 바로 해제한다.
• 무상태성(Stateless), 비연결성
  • TCP로 서버와 클라이언트를 연결 한 후 요청에대한 응답만 처리하고 연결을 종료하여, 연결상태를 유지하지 않는 비연결성 프로토콜 이다.
  • 상태정보를 저장하지 않고 그때그때의 요청에 대해서만 응답을 처리한다는 점에서무상태성의 특성을 띈다.
  • 비연결성의 문제를 해결하기 위해 Cookie와, Session을 사용한다.
• HTTP가 전체 인터넷 프롵토콜에서 위치하는 곳은 응용계층이다.
  • 응용계층(DNS, FTP, HTTP)
  • 전송계층(TCP, UDP, SCTP)
  • 네트워크계층(IP, ARP, RARP)
  • 링크계층(이더넷, 토큰링, WIFI)

 

복습 겸 TCP/IP를 다시한번 살펴보자

2) TCP/IP

 HTTP뿐만아니라 FTP, SMTP등의 프로토콜이 동작하는 프로토콜이다. TCP/IP는 이름에서 볼 수 있듯 IP와 TCP 프로토콜로 이루어져있다. IP의 순서가 조금 바뀌거나 누락되더라도 보내는 성질과 조금 느리지만 꼼꼼한(수신측에서 재배열) TCP의 성질을 함께 사용하는 것이다.

  패킷 통신 방법의 발전과 TCP/IP에 대한 내용은 아래 페이지에서 잘 설명해 놓았다. 아래 내용에서 필요한 내용은 요약해 놓았으나 자세히 들여다 보고 싶으시면 참고해 보시라.

https://brunch.co.kr/@wangho/6

• IP(Internet Protocol)
  • OSI 7 Layer의 3계층(네트워크) 혹은 TCP/IP의 4Layer의 2계층(인터넷 계층)에서 사용되는 프로토콜로 Routing을 통해 Packet을 전달하는 역할을 한다.
  • 4바이트로 이루어진 주소번호를 사용하여 node를 구분하고 목적지를 찾아가게 된다.
  • 논리적 주소 - 유일한 주소이지만 바꿀 수 있다.
  • 비연결형 - 연결을 유지하지 않으면서 정해진 길이가 없어 쪼개진 데이터들이 독립적으로 보내서 수신 순서가 송신 순서와 다를 수 있다.
  • 비 신뢰성 - 데이터가 올바르게 전송된다는 보장이 없다. 받은 쪽에서 패킷이 분실, 손상될 수 있다.
  • IP 프로토콜은 각 패킷의 주소 부분을 처리하며 목적지에 정확하게 도착 할 수 있게 한다.
• TCP
  • OSI 7 Layer의 4계층(전송) 혹은 TCP/IP의 4Layer의 3계층(전송 계층)에서 사용되는 프로토콜로 통신 노드를 연결하고 데이터 전송을 담당한다.
  • 서버와 클라이언트간 데이터를 신뢰성 있게 전달하기 위한 프로토콜이다.
  • 데이터 전달과정에서 생기는 손실이나 오류를 교정하여 순서재조합, 재전송요청등을 통해 신뢰성 있는 통신을 보장한다.
  • 연결지향프로토콜이다. 이전 포스트(2021.05.19 - [ComputerScience/Network] - [Network] 1. OSI 7계층, TCP/IP 4계층, 3way/4way hanshake)에서 다룬 3way handshake를 통해연결과정을 거쳐 연결 이후 통신을 한다.
  • TCP프로토콜은 메시지를 좀 더 작은 단위의 data인 패킷으로 나누어 인터넷을 통해 전송하는 일과 수신된 패킷을 원래 메시지로 재 조립하는 일을 담당한다.

TCP는 data의 추적을 담당하고 IP는 배달을 담당한다고 볼 수 있다.

 

※ IP프로토콜은 신뢰성이 없는 프로토콜인데 이 위에서 돌아가는 TCP프로토콜이 신뢰성 있게 동작 할 수 있는 이유

 IP 헤더, TCP 헤더라는 말을 들어 봤을 것이다. TCP데이터에 TCP헤더를 붙여 하위 계층인 인터넷 계층으로 전달하면 IP헤더를 붙여 전송하게 된다.

 이 데이터는 신뢰성이 없게 상대방에게 전달되고 전달 중 오류가 있거나 전송이 되지 않은 데이터에 대해서 수신측에서 TCP프로토콜에 의해 오류제어, 흐름제어를 통해 신뢰성을 얻는 것이다.

3) Reqeust & Response

 HTTP 통신은 클라이언트 측에서 정보를 Request하고 서버가 이에대해 Response하는 형식으로 진행되는 통신이다. 

• Request는 그 통신 내용에 따라 GET, POST, PUT, DELETE 등의 메서드를 사용하여 요청을 하는데 각각 정보를 조회, 추가, 수정, 삭제 할 때 주로 사용한다.
• Response는 해당 Request에 대한 응답메세지인데 여기에는 클라이언트가 요청한 메세지(Response Message)와 요청코드(Statuscode)를 포함한다.
• Statuscode에 따라 요청이 올바른 요청인지, 권한은 알맞은지 등을 파악할 수 있다.

- Statuscode

1. XX(조건부 응답) - Informational
   • 조건부 응답으로, 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다.  -> 거의 만날일이 없는 상태코드이다.
2. XX(성공) - Success
   • 요청을 성공적으로 받았으며 인식했고 수용했다.
3. XX(리다이렉션 완료) - Redirection
   • 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
   • 클라이언트에 대해 적절한 다른 위치를 제공하거나, 대안의 응답을 제공한다.
4. XX(요청오류) - Client Error
   • 클라이언트의 요청에 오류가 있다.
   • 클라이언트의 요청이 올바르지 못하거나 권한, URL에 대한 잘못된 접근 등 클라이언트의 요청이 잘못된 경우이다.
5. XX(서버오류) - Server Error
   • 서버가 유효한 요청을 명백하게 수행하지 못했다.
   • 서버의 오류, 서버의 일시 사용중단, 서버의 응답지연(다른서버와의 통신에서) 등 서버의 문제로 응답할 수 없는 상태를 말한다.

 4) HTTP 내용

 [1] Header

HTTP 1.1에서 헤더는 세 부분으로 나눌 수 있습니다.

1. 일반헤더(General Header)
   • 본문과 관련이 없는 내용으로 Request/Response가 생성된 DATETIME 같은 HTTP통신에 대한 일반적인 정보로써 Request/Response 메세지에 공통적으로 사용된다.
   • Date, Connect, Cache-Control, Content-Type(컨텐츠 타입(MIME), 문자열인코딩(utf-8)등 ), Content-Language, Content-Encoding
   • ex) Date: Fri, 21 May 2021 19:43:10 GMT
2. 요청/응답헤더(Request/ Response Header)
   • 클라이언트가 요청을 할 때에는 요청헤더, 서버에서 응답메세지를 보낼 때는 응답헤더이다.
   • 요청헤더
     • 요청한 URL, 메소드(GET, POST, HEAD), 요청 생성에 사용 된 브라우저 정보등이 포함된다.
     • ex) User-Agent:
       Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36"
     • 개발자도구(F12)의 콘솔창에 navigator.userAgent를 입력하면 해당 정보(브라우저정보)를 확인할 수 있습니다.
   • 응답헤더
     • 클라이언트의 요청에 대해 서버에서 수신되며 컨텐츠에 사용된 인코딩, 서버 시스템에서 응답을 생성하는 데 사용되는 웹서버 정보, 서버 소프트웨어 및 기타 정보를 포함한다.
     • 예시
       • Server => 서버 소프트웨어 정보
       • Set-Cookie => 세션 쿠키 정보를 설정
       • Expires => 응답 컨텐츠가 만료되는 시간을 나타낸다.
       • Allow => 해당 엔티티에 대해 서버에서 지원 가능한 메소드를 나타낸다.
         • ex) Allow: GET, HEAD
         • 405 Method Not Allowed와 함께나타난다. 
       • Access-Controll-Allow-Origin => 요청을 보내는 주소(URL)와 응답하는 주소가 다르면 CORS에러가 발생하는데 이때 Access-Controll-Allow-Origin헤더에 프론트에서 사용한 주소를 적거나 *(모든주소)를 적어줘야 에러가 나지 않습니다. (*는 보안에 취약해 짐)
         얘를 들면 www.naver.com/ 을 접근한 후에 이에대해 www.naver.com/image.jpg  리소스와 www.naver.com/layout.css를 접근한다면 same-origin request로 허용되지만 처음부터 image파일과 layout파일을 요청한다면 origin이 달라 CORS 에러를 발생하는 것이다. 다음 링크에 자세한 설명이 있다.(https://developer.mozilla.org/ko/docs/Web/HTTP/CORS) - origin의 구성요소는 protocol/ host/ port를 말한다. 이것이 다를때 발생하는 것이다.
       •  
3. 엔티티헤더(Entity Header)
   • 실제 메세지 또는 전송중인 HTTP 본문에 대한 정보가 포함된다. 컨텐츠 길이, 언어, 인코딩, 만료날짜 및 기타 중요한 정보등을 포함한다.

 [2] Body(HTTP 본문)

실제 컨텐츠가 들어가는 부분으로 요청한 리소스에 따라 HTML, 이미지, CSS, JavaScript등이 포함된다.

 

5) HTTP 메소드

HTTP 메소드는 클라이언트가 하고 싶은 작업을 서버에 전달하는 역할을 한다.

1. GET
   • 가장 흔히 사용되는 메서드로 리소스를 요청할 때 사용된다.
   • 주로 쿼리 파라미터를 통해 전달한다(URL)
2. POST
   • 서버에 데이터를 전송하여 입력(추가)하려고 사용한다.
   • 서버는 요청메세지의 BODY를 통해 들어온 데이터를 저장한다.
3. PUT
   • POST와 유사한 전송 구조를 가져 헤더 이외의 데이터가 함께 전송된다.
   • 서버에 BODY를 저장하기 위해 사용되지만 기존 정보르 변경하는 역할을 한다.
4. PATCH
   • PUT과 같은 역할이지만 데이터의 전체가 아닌 일부를 변경하기 위해 사용된다.
5. DELETE
   • 서버의 파일을 삭제하기 위해 사용된다.
6. HEAD
   • GET과 유사한 방식이지만 응답메시지로 헤더 정보만을 보낸다.
   • 서버의 다운여부 점검 혹은 정보를 얻기위해 사용된다.
7. OPTION
   • 시스템에서 지원되는 메소드의 종류를 확인할 수 있다.
8. TRACE
   • 서버에 LoopBack 메시지를 호출하기 위해 사용된다.
   • 클라이언트가 서버에 요청을 하면 중간에 방화벽, 프록시, 게이트웨이 등의 애플리케이션을 통과할 수 있는데 이 과정에서 메시지 수정이 될 수 있다. 이를 점검하기 위해 TRACE메서드를 사용한다.
   • 서버가 TRACE 메서드에 응답할 때 요청메시지를 본문에 넣어 응답한다.(수정사항 검토 가능)
9. CONNECT
   • 서버에 프록시 기능을 요청할 때 사용된다.

※프록시서버

 프록시 서버는 Client와 Server가 통신할 때 중간에서 자신을 거쳐서 통신할 수 있게 해주는 서버이다. 프록시 서버를 사용하는 이유는 다음과 같다.

• 캐시데이터 사용 : 프록시 서버는 요청내용을 캐시에 저장해 두는데 캐시에 저장되어 있는 내용에 대한 요청은 서버에 따로 접속할 필요가 없어 저장해 둔 내용을 클라이언트에게 돌려주어 시간절약과 트래픽 감소로 인한 네트워크 병목현상을 방지한다.
• 보안 목적 :  프록시서버를 경유하면 IP를 숨기는 것이 가능하고, 프록시 서버를 방화벽으로 사용하기 때문에 보안기능을 할 수 있다.
• 접속 우회 : 간혹 한국에서 접속이 제한되는 사이트를 만날 수 있는데 이 경우 프록시 서버(다른나라)를 사용하여 접속을 다른나라로 우회할 수 있다.

HTTP Method	요청에 Body	응답에 Body	안전	멱등	캐시가능
GET	NO	YES	YES	YES	YES
HEAD	NO	NO	YES	YES	YES
POST	YES	YES	NO	NO	YES
PUT	YES	YES	NO	YES	NO
DELETE	NO	YES	NO	YES	NO
CONNECT	YES	YES	NO	NO	NO
OPTIONS	선택사항	YES	YES	YES	NO
TRACE	NO	YES	YES	YES	NO
PATCH	YES	YES	NO	NO	YES

멱등부분은 계속하여 같은 요청을 할 때 같은 결과가 나오는 것을 말합니다.

 

2. HTTPS

  HTTP 프로토콜은 다른 시스템간 통신을 위한 기초적인 텍스트 전송 프로토콜이다. 하지만 암호화가 되지 않아 메시지를 감청당할 위험이 있다. 따라서 Socket Layer을 이용해 보안통신을 하는 HTTPS 방식이 등장했다. 이것이 HTTP와 SSL(Secured Socket Layer)를 합친 HTTPS방식이다.

 기존의 HTTP에서 소켓과 통신하는 부분을 SSL(TLS)라는 프로토콜로 대체한 것이다. 즉, 원래 TCP와 직접 통신을 했지만 HTTPS에서는 SSL과 직접 통신을 하며, SSL이 TCP와 통신을 하게 된다.

 

 HTTPS개념은 글로 읽기에는 매우 어려운 내용이라고 생각한다. 필자 또한 이 개념을 생활코딩님?의 영상을 보고 이해했다.https://opentutorials.org/course/228/4894

HTTPS와 SSL 인증서 - 생활코딩

이 튜토리얼에서는 사용하는 방법까지 나와있으나 큰 제목으로 SSL의 동작방법까지 보면 SSL과 HTTPS의 관계와 동작 원리에 대해서 잘 이해가 갈 것으로 생각된다.

 목소리가 정말 좋으신데 남자라서 좋은 남자 목소리를 들을 필요가 없어 1.25~1.5배를 선호한다.(성격이 급한 필자에게는 말하시는 속도가 조금 느리다..)

 

 

 - HTTPS 동작원리

우선 HTTPS 또한 TCP/IP 프로토콜을 사용한 통신 방법이니 맨 처음에는 3-way-handshaking으로 시작한다는 점을 유의해야 된다.

 

서버가 CA의 인증기관의 인증을 받는 방법을 알아보기 전에 HTTPS에 사용되는 대칭키와 비대칭키의 기본적인 메커니즘을 이해할 필요가 있다.

 

비대칭키 알고리즘

- 공개키(비대칭 키) 암호화 방법

•  우선 비대칭키는 평문에서 암호문을 만들 때 오직 공개키를 사용하면 복호화 할 때 오직 비밀 키를 사용하여 복호화 해야한다.
• 반대로 비밀키를 사용하여 암호화 했다면 공개키를 이용하여 복호화 해야한다.
• 비밀키는 해당 키를 만든 사용자(서버)만 가지고 있기 때문에 키를 공개적으로 배포하여 서버와 통신시 해당 키로 암호화를 하게 한 후 서버와 요청을 시도하는 클라이언트의 요청을 비밀키로 복호화 하여 처리한다.
•  비대칭키 암호화 방식은 대칭키 암호화 방식보다 느리지만 비밀키를 한 호스트만 가지고 있다면 중간에 탈취당해도 그 내용을 감청당할 가능성이 매우 적다는 장점이 있다.

- 비밀키(대칭 키) 암호화 방법

• 대칭키는 암호화를 할 때와 복호화를 할 때 같은 키를 사용한다.
• 비대칭키 방법에 비해 1000배정도 더 빠른 암/복호화가 가능하다.

 

- HTTPS에서 사용하는 방식

두가지의 방식을 보면 비대칭 키는 대칭키 암호화방식보다 더 느리지만 안전한 방법이다. 반면에 대칭키에 비해 매우 느린 암/복호화 속도를 가지고 있다. 따라서 HTTPS에서는 두가지를 방법을 혼합한 방법을 사용한다.

 통신을 하는데는 대칭키를 사용하고 그 대칭키를 초기에 나눠 갖을 때는 비대칭 키를 이용하여 키를 나눠 갖는 SSL 핸드쉐이킹 방법을 사용한다.

 

SSL핸드쉐이킹 과정을 하기전 즉, 브라우저와 HTTPS 통신을 하기전에 서버는 CA라는 서버 인증기관의 승인을 먼저 받아야 한다.

 다음은 서버가 CA의 인증을 받는 과정이다.

 

 

1.  서버는 공개키와 비밀키 쌍(파란색)을 생성한다. 비밀키는 서버가 소유하고 있는다.
2. CA에 공개키와 해당 서버의 정보(인증을 하기위한)를 전송한다.
3. CA가 해당 서버가 안전한 서버인지 심의를 통해 인증을 하게된다.
4. .CA에서도 공개키와 비밀키 쌍(빨간색)을 생성한다.
5. CA는 서버가 전송한 공개키와 서버 정보를 포함한 인증서를 만들고 CA가 만든 비밀키로 암호화한다.
6. 암호화한 서버의 공개키는 다시 서버로 보내고, 여러 브라우저(크롬, 파이어폭스, 사파리..)에 CA에서 만든 공개키를 전송(배포)한다.

이로서  SSL 핸드쉐이크의 사전작업이 끝났다.

 위 언급한 바와 같이 SSL핸드쉐이크 과정은 클라이언트와 브라우저가 통신을 할 때 사용할 대칭키를 나누어 갖는 과정이다.

 

조금 복잡해 보일 수 있지만 최대한 보기 쉽게 만드려고 노력했다..

 

다시한번 말하지만 글로 이해하기 조금 어려울 수 있다. 최대한 쉽게 쓰려고 노력했지만, 이해가 안되더라도 이상한게 아니다. 이해가 잘 안되면 위에 남겨놓은 생활코딩에서 동영상을 통해 쉽게 이해해 보자.

1. Client Hello : 클라이언트는 비밀키를 만들때 사용될 랜덤데이터(Client), 브라우저에서 사용가능한 암호화 방법의 리스트를 서버에 전송한다.
2. Server Hello : 서버는 암호화 방법 중 서버도 사용 가능한 암호화 방법1개와 서버에서 만든 랜덤데이터(Server), 그리고 CA에서 받은 암호화 된 인증서를 클라이언트에게 보낸다.
   2-1. 클라이언트의 브라우저에는 CA가 배포한 공개키가 있다. 만약 서버가 CA에서 인증한 기관이라면 암호화된 인증서는 CA의 비밀키로 암호화 되어있다는 것을 의미하고 그에 대응되는 CA가 배포한 브라우저 내장 공개키는 이를 복호화 할 수 있다.(이해가 잘 안가면 비대칭키 메커니즘을 다시 보길 바란다.)// 공개키로 복호화 가능한 것은 오직 비밀키를 사용해 암호화한 평문밖에 없다.
   2-2. 따라서 인증서가 복호화 된다는 것은 CA가 인증한 기관이라는 것을 알 수 있고 클라이언트는 이 사이트를 신뢰성 있는 사이트라고 생각할 수 있는 것이다.
   2-3. 이 점이 비대칭키를 이용한 신뢰가능한 기관 인증방법이다.
3. 클라이언트는 랜덤데이터(Server)와 랜덤데이터(Client)를 이용하여 Pre master Secret이라는 키를 생성하고 이를 인증서에서 얻은 공개키로 암호화합니다.(이는 서버의 비밀키 밖에 복호화를 하지 못합니다. 서버의 비밀키는 CA에 인증을 하는 단계에서 생성한 키이며 서버만이 보유해야 합니다.)
4. 통신을 하기위한 대칭키인 Session Key를 나눠 갖는 프로세스를 마쳤으며 통신을 하고 통신을 마치면 세션을 종료합니다.

이 과정은 매우 빠르게 일어나며 중간에 메세지를 탈취해 해독을 한다고 해도 시간이 오래 걸릴 뿐만 아니라 세션 종료시 Session Key는 폐기되어 매우 안전한 방법이라고 한다.

 

 

※

의문점 : 중간에 주고 받은 랜덤 데이터는 탈취될 위험이 있고, 서버는 클라이언트에서 생성한 Premaster Secret을 이용하여 Session Key를 만들기 때문에 Client Hello단계에서 클라이언트는 랜덤데이터를 줄 필요가 없을 수 있다는 점이 의문점이다.

 

==> 디피-헬만 키교환 방식에 따르면 초기 매우 큰 소수를 나눠갖는 과정이 랜덤데이터를 나눠 갖는 과정이라고 생각하면 될 것 같다.

https://reakwon.tistory.com/138

[암호학] 디피-헬만 키 교환 개념 설명 및 예제(Diffie-Hellman), 중간자 공격

디피-헬만 키교환 방식은 위 포스트를 참고 했으니 궁금하신 분은 보고 오시면 된다.(대략적인 과정을 보면 된다.)

 

요약하자면 A와 B가 개인키를 나눠 같는 과정인데 (key^a mod p)^b mod p== key^ab mod p 라는 성질을 이용하여 a와 b를 서로 가지고 있고(공개하지 않으면서) (key^a mod p) 값과 (key^b mod p) 값을 서로 공유하는 방식입니다.

 

 이 방법이 그대로 사용됐지는 않았겠지만 이런 식으로 자신과 상대방의 랜덤데이터를 사용해서 하나의 값(pre master secret)으로 만든 후 각자의 알고리즘을 통해 자신만의 키로 같은 Session Key를 만들 수 있는 것 같습니다.

( 랜덤키가 양쪽에 있어야 되는 이유 중 하나의 예시 )

 

 

- SSL

HTTPS에서 사용하는 Secured Socket Layer의 약자로 일반적인 인터넷 프로토콜은 기밀성을 유지하지 못하기 때문에 이를 보완하기 위해 데이터를 안전하게 전송하기 위한 통신 규약 프로토콜이다. SSL위에서 HTTP가 동작하면 HTTPS, FTP가 동작하면 SFTP가 된다.( 꼭, HTTPS에만 사용되는 것이 아니다.)

 - TLS

 SSL이 표준화 기구인 IETF에 넘어가며 TLS로 이름이 변경되었다. 즉, TLS가 SSL을 계승하게 되었고 SSL의 공식적인 이름이라고 생각하면 된다.

 

https://velog.io/@doomchit_3/Internet-HTTP-개념차렷-IMBETPY
https://brunch.co.kr/@wangho/6(TCP/IP) 
https://blueyikim.tistory.com/1999 
https://velog.io/@wonhee010/OSI-7계층-TCPIP-4계층에-대해서-2 (TCP/ IP)
https://backkom-blog.tistory.com/entry/entry/Chrome크롬-웹-브라우저-User-Agent-확인하기
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS (HTTP메서드)
https://gyrfalcon.tistory.com/entry/HTTP-응답-코드-종류-HTTP-메소드-종류 (HTTP메서드)
https://velog.io/@proshy/네트워크HTTP-method (HTTP메서드)
https://liveyourit.tistory.com/251(프록시 서버)
https://www.leafcats.com/202(SSL, TLS) (SSL 핸드쉐이크)
https://hanjungv.github.io/2017-11-07-1_CS_SSL/ (SSL 핸드쉐이크)