HTTP & HTTPS

코난·2023년 12월 6일

CS 면접 정리

목록 보기

19/76

HTTP

HTTP란?

HTTP는 Hypertext Transfer Protocol의 약자로, 서로 다른 시스템들 사이에 통신을 주고 받게 해주는 가장 기본적인 프로토콜
서버-클라이언트 모델(클라이언트가 요청을 생성하기 위한 연결을 연 다음 응답을 받을때까지 대기하는 모델)에 맞춰 데이터를 주고 받기 위한 프로토콜
80번 포트를 기본적으로 사용함
HTTP는 정보를 텍스트 기반의 평문으로 주고 받기 때문에 네트워크에서 정보를 탈취하거나 변조할 수 있는 보안적 위험이 있음

HTTP 특성

Connectionless 프로토콜(비연결 지향)

클라이언트가 서버에 요청했을 떄, 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식

Stateless 프로토콜

커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있음
클라이언트와 첫번째 통신에서 데이터를 주고받았다 해도, 두번째 통신에서 이전 데이터를 유지하지 않음 (하지만 데이터 유지가 필요한 경우가 많음)

쿠키 & 세션

Stateless에 대처하기 위해 Stateful하게 만드는 방법
쿠키
- 클라이언트가 사이트에 방문할 경우 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일임
- HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있음
- 동작 과정
  1. 클라이언트가 페이지를 요청
  2. 웹 서버는 쿠키를 생성
  3. 생성한 쿠키에 정보를 담아 HTTP 응답을 돌려줄 때 같이 클라이언트에 돌려줌
  4. 넘겨받은 쿠키는 클라이언트가 로컬에 저장하여 가지고 있다가 다시 서버에 요청할 때 요청과 함께 쿠키 전송
  5. 동일 사이트 재방문시 클라이언트 PC에 해당 쿠키가 있는 경우 요청과 함께 쿠키 전송
- 사용 예시
  - 로그인 정보 저장, 팝업창 오늘 이 창 다시 보지 않기
세션
- 일정 시간동안 같은 클라이언트로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술
- 일정 시간이란 방문자가 웹 브라우저는 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점까지
- 방문자가 웹 서버에 접속해있는 상태를 하나의 단위로 보고 그것을 세션이라 함
- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장함(웹 서버에 저장되는 쿠키)
- 브라우저를 닫거나 서버에서 세션을 삭제했을때만 삭제가 되므로 쿠키보다 비교적 보안이 뛰어남
- 저장 데이터에 제한이 없음
- 각 클라이언트에 고유 Session ID를 부여함. 이를 이용해 클라이언트를 구분함
- 동작 순서
  1. 클라이언트가 페이지를 요청
  2. 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여 클라이언트가 해당 session-id를 보냈는지 확인
  3. session-id가ㅏ 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에 넘겨줌
  4. 클라이언트는 서버로부터 받은 session-id를 쿠키에 저장
  5. 클라이언트는 서버에 요청시 이 쿠키의 session-id값을 같이 서버에 전달
  6. 서버는 전달받은 session-id로 session에 있는 클라이언트 정보를 가지고 요청을 처리 후 응답
- 사용 예시
  - 화면을 이동해도 로그인 유지 (로그아웃 전까지)
쿠키 VS 세션
- 세션도 결국 쿠키를 사용하기에 동작 원리가 비슷하지만 큰 차이점은 사용자의 정보가 저장되는 위치임
  - 쿠키는 서버의 자원을 전혀 사용하지 않지만 세션은 서버의 자원을 사용함
- 쿠키는 보안에 취약하지만 세션은 쿠키를 이용해 session-id를 저장하고 이로 클라이언트를 구분해 처리하기에 보안성이 높음
- 쿠키는 파일로 저장되어 브라우저를 종료해도 정보가 유지될 수 있으나 세션은 브라우저가 종료되면 만료기간과 상관없이 삭제됨
- 속도면에서는 쿠키가 더 우수함
  - 쿠키는 쿠키에 정보가 모두 있어 서버 요청시 속도가 빠르고, 세션은 정보가 서버에 있기 때문에 처리가 추가로 요구되어 비교적 느림

HTTP의 문제점

평문 통신이기에 도청이 가능함 -> 암호화로 해결
- 통신 자체를 암호화하거나(HTTPS) 데이터를 암호화하는 방법등이 있음
- 데이터를 암호화하는 경우에는 수신측에서 복호화 과정이 필요함
완전성을 증명할 수 없기 때문에 변조가 가능함 -> 암호화로 해결
- HTTPS에서는 메세지 인증 코드(MAC), 전자 서명등을 통해 변조 방지
통신 상대를 확인하지 않기 때문에 위장이 가능함 -> 인증
- 의미없는 리퀘스트도 수신하기 때문에 DOS 공격을 당할 수 있음
- 통신하고 있는 상대방이 허가된 상대인지 확인할 수 없음
- HTTPS에서는 CA 인증서를 통해 인증된 상대와 통신이 가능

HTTPS

HTTPS란?

Hypertext Transfer Protocol + Secure Socket Layer의 의미를 가짐
HTTP 메세지에 포함되는 콘텐츠 정보에 보안 요소(암호화)가 추가되는 것이 큰 차이점
모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 SSL 계층을 통해 암호화됨
HTTPS는 HTTP 하부에 SSL 또는 TLS의 보안 계층이 추가됨
HTTP와 다르게 443포트를 기본적으로 사용함

HTTPS 보안 작동 방식

<인증서 발급>

1. 서버는 공개키와 개인키를 만든 후, 신뢰할 수 있는 인증기관(CA)에 자신의 정보와 공개키를 관리해달라고 계약한다.
2. 인증 기관은 서버가 제출한 데이터를 검증한다. 검증을 완료하면 인증 기관만의 개인키로 서버에서 제출한 정보를 암호화한다.
3. 암호화된 인증서를 만들어 서버에게 제공해준다.
4. 인증기관은 웹브라우저에게 인증기관의 공개키를 제공한다.

(웹브라우저는 브라우저가 자동으로 신뢰하는 CA 인증서 집합이 사전 구성되어있고, 설치될때 함께 설치된다. 이 공개키를 사용하여 웹 서버의 인증서가 실제로 신뢰할 수 있는 인증기관에서 서명되었는지 확인한다.)

<서버에 데이터 요청>

1. 클라이언트(웹브라우저)가 사이트에 접속한다.
2. 서버는 자신의 인증서를 클라이언트에게 보낸다. (이때의 인증서는 인증기관이 만들어준 인증서)
3. 클라이언트는 브라우저에 미리 저장되어 있는 인증기관의 공개키로 인증서를 해독한다. 해독하여 검증하는 과정에서 접속하려는 서버의 정보와 서버의 공개키를 알게된다.(인증기관이 인증서를 만들때 이러한 정보를 가지고 만들기 때문)
4. 얻은 서버의 공개키를 이용하여 대칭키를 생성한다. (이때 대칭키를 굳이 생성하는 이유는 비대칭키보다 훨씬 계산이 효율적이기 때문이다. 처음 연결을 설정할 때에만 비대칭키 암호화를 사용하고, 이후 통신에서는 대칭키 암호화를 사용한다.)
5. 서버의 공개키로 위에서 생성한 대칭키를 암호화해서 사이트에 보낸다.
6. 서버는 서버의 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이제 양쪽이 대칭키를 이용해 데이터를 주고받을 수 있게 된다.

계속 대칭키를 사용해 데이터를 주고받다가 세션이 종료되면 대칭키를 폐기한다.
(클라이언트와 서버 간의 특정 세션 동안에만 사용되는 암호키이기 때문에 이 대칭키를 세션키라고 부르기도 한다.)

이 과정 자체를 SSL/TLS handshaking이라고 부르기도 한다.

HTTPS 단점

HTTPS 설치 및 인증서 유지에 추가 비용이 발생
암호화 과정이 웹 서버에 부하를 줌
HTTP에 비해 속도가 느림
인터넷 연결이 끊긴 경우 재인증 시간이 소요
- HTTP는 비연결형으로 웹페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지 계속 볼 수 있음
- HTTPS는 소켓 자체에서 인증을 하기 때문에 인터넷의 연결이 끊기면 소켓도 끊어져서 다시 HTTPS 인증이 필요해짐