03. 기술면접 - 네트워크 - HTTP 와 HTTPS 프로토콜

공부목적으로 다른 블로그의 글을 그대로 따라치면서 작성되었습니다. 저작권 문제 시, 비공개 처리하겠습니다

 

HTTP 프로토콜

- 개념 
    - Hyper Text Transfer Protocol
    - 하이퍼 텍스트 교환 방식 (Hyper Text) -> HTML (Hyper Text Markup Language)
    - 웹상에서 클라이언트와 서버간에 요청/응답(request/response) 으로 정보를 주고 받을 수 있는 프로토콜

- 특징
    - 주로 HTML 문서를 주고 받는 데 쓰인다
    - 주로 HTML 문서를 주고 받는 데 쓰인다
    - TCP 와 UDP 를 사용하며 80번 포트를 사용한다
    - 비연결(Connectionless)
        - 클라이언트가 요청을 서버로 보내고 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊어진다
    - 무상태성(Stateless)
       - 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다
       - 이전에 요청한 결과를 갖고있지 않는다

HTTPS 프로토콜

- 개념
    - Hyper Text Transfer Over Secure Socket Layer ( 또는 HTTP over TLS, 또는 HTTP over SSL 이라고도 불린다)
    - 웹 통신 프로토콜인 HTTP 에 보안을 강화한 프로토콜이다
    - HTTP 프로토콜에 데이터 암호화가 추가된 프로토콜

- 특징
    - HTTPS의 기본 TCP/IP 포트로 443 포트를 사용
    - HTTPS 는 socket 통신에서 일반 텍스트를 이용하는 대신에, 웹 상에서 정보를 암호화하는 SSL 이나 TLS 프로토콜을통해 세션 데이터를 암호화한다

    - TLS(Transport Layer Security) 프로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것이다
    - 두 프로토콜으 주요 목표는 기밀성(사생활 보호=개인정보), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공한다
    - 데이터의 적절한 보호를 보장한다
        - 보호의 수준은 개발자의 웹 구현능력과 암호화 알고리즘에 달리게 된다

    - https 프로토콜을 적용하는 이유는 클라이언트와 서버간의 통신 중 데이터를 탈취했을 때 데이터를 알아볼 수 없게 보안하기 위함이다
    - 사용자의 데이터를 공개키 암호화(공개키를 얻은 인증된 사용자)
    - 서버로 전송 (데이터를 가로채도 개인키가 없으므로 복호화할 수 없다)
    - 서버의 개인키를 통해 복호화 하여 요청을 처리한다

- HTTPS 의 장단점
    - 장점
        - 네트워크 상에서 열람, 수정이 불가능하므로 안전하다

    - 단점
        - 암호화를 하는 과정이 웹 서버에 부하를 준다
        - HTTPS 는 설치 및 인증서를 유지하는 추가 비용이 발생 (유료)
        - HTTP 에 비해 느리다 (오늘날에는 크게 느껴지지 않는다)
        - 인터넷 연결이 끊긴 경우 재인증 시간이 소요된다
            - HTTP 는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있다
            - 그러나 HTTPS 의 경우에는 socket(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 socket 도 끊어져서 다시 HTTPS 인증이 필요하다

 

티스토리의 HTTPS 인증서 정보이다 (공개키로 암호화하여 해당 서버에서 인증한 정보임을 알려 사용자들은 신뢰성을 보장받는다)

HTTPS 암호화 와 복호화

https 과정

 

HTTP(S) 요청 응답 헤더

• HTTP 헤더 내 일반 헤더 (General Header 항목)
  • 요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의 (기본적인) 헤더 항목
  • 주요 항목들
    • Date : HTTP : 메시지를 생성한 일 시
    • Connection : 클라이언트와 서버 간 연결에 대한 옵션 설정
      • Connection : close -> 현재 http 메시지 직후 tcp 접속을 끊는다는 것을 알림
      • Connection Keep-Alive -> 현재 tcp 커넥션을 유지
    • cache-control
    • pragma
    • trailer

네이버 Network 캡처

• HTTP 헤더 내 엔티티/개체 헤더 (Entity Header) 항목
  • 콘텐츠, 본문, 리소스
    • Content-Type
    • Content-Encoding
    • Content-Length
    • ....

• HTTP 헤더 내 요청 헤더 (Request Header) 항목
  • Host : 호스트명 또는 호스트명+포트
  • User-Agent : 클라이언트명 (크롬, 사파리 등..)
  • Cookie : 모든 쿠키 정보
  • Referer : 이전 페이지 주소
  • If-Modified-Since : 제시한 일시 이후로만 변경된 리소스를 취득 요청
  • Authorization : 인증 토큰 담는 곳
  • Origin 
    • 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄
    • 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
    • 응답 헤더의 Access-Control-Allow-Origin와 관련

• HTTP 헤더 내 응답 헤더 (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.zerocho.com
        • 프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
      • Access-Control-Allow-Origin: *
        • 만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
      • 유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.  

        

        스프링에서는 위와 같이 해당 헤더를 설정하여 요청을 허용할 주소를 명시해준다

 

HTTP 와 HTTPS 동작 과정

HTTP 동작 과정
서버 접속 -> 클라이언트 -> 요청 -> 서버 -> 응답 -> 클라이언트 -> 연결 종료

①. URL 을 통한 서버 접속 (http://www.naver.com)
②. DNS 서버에 의해 웹 서버의 호스트 이름을 IP 주소로 변경 (http://www.naver.com -> http://123.4567.12:8080)
③. 웹 서버와 연결 시도 (3 way handshaking) -> 핸드 쉐이킹 거친 후 서버와 연결완료
④. 클라이언트가 서버에게 요청=Request (GET) 
    - HTTP Request Message = Request Header + 빈 줄 + Request Body
    - Request Header
        - 요청 메소드 + 요청 URI + HTTP 프로토콜 버전
            - GET /background.png HTTP/1.0 POST / HTTP 1.1
            - Header 정보(key-value 구조)
    - 빈 줄
        - 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도
    - Request Body
        - GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 바디 미포함
        - 데이터 업데이트 요청과 관련된 내용 (HTML 폼 콘텐츠 등)
⑤. 서버가 클라이언트에게 데이터 응답
    - HTTP Response Message = Response Header + 빈 줄 + Response Body
    - Response Header
        - HTTP 프로토콜 버전 + 응답 코드 + 응답 메시지
            - ex. HTTP/1.1 404 Not Found.
        - Header 정보(key-value 구조)
    - 빈 줄
        - 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도
    - Response Body
        - 응답 리소스 데이터
            - 201, 204 상태 코드는 바디 미포함

 

HTTP 프로토콜에서 사용한다는 TCP 와 UDP 에 대한 이해

HTTP 는 비연결성이다. 하지만 TCP 는 연결성이다
둘 다 프로토콜이고 HTTP 는 TCP 기반으로 만들어진 프로토콜이라고 한다
HTTP 는 OSI 7 계층 중 Application Layer 이며, TCP 와 UDP 는 Trasnfer Layer 이다
때문에 TCP 로 요청 (request) 와 응답(response) 은 하나의 연결성을 가지고 있다
그리고 서버로 부터 응답이 된 후에는 HTTP 프로토콜 특성상 연결을 끊어버린다 
연결을 끊어버렸기 때문에 상태를 갖지 않고 있어 stateless (무상태성) 인 것 이다
통은 TCP 기반으로 socket 통신하며 Streaming 서비스를 해야하는 경우 UDP 기반 socket 통신을 사용한다
HTTP 버전 1 보다는 HTTP 버전 2 가 빠르며 HTTP 버전 3 도 있는데 HTTP 버전 3은 UDP 기반 통신이다

공개키와 대칭키 간단 요약

- 대칭키 암호화
    - 하나의 비밀키로 암호화 복호화 (클라이언트 & 서버 같은 비밀키 사용)
    - 보안에 취약
    - 속도가 공개키보다 빠름

- 공개키 암호화 = 비대칭키 암호화 > 예) SSL
    - 공개키와 비밀키를 갖으며 공개키로 암호화 하며, 비밀키로 복호화를 진행 (클라이언트 암호화, 서버 복호화)
    - 보안에 강함
    - 속도는 대칭키보다 느림
    - 공개키를 통해 누구나 암호화 할 수 있지만 복호화는 비밀키를 갖고 있는 서버만 가능하게 된다

HTTPS 암호화 방식
공개키 암호화 방식과 대칭키 암호화 방식의 장점을 활용해 하이브리드 사용 데이터를 대칭키 방식으로 암복호화하고, 공개키 방식으로 대칭키 전달

https://gaeko-security-hack.tistory.com/123

 

OKKY 참고

https://okky.kr/article/787738