SSL/TLS란?

  • HTTP를 이용하여 데이터를 전송할 때, 우리가 주고받는 데이터는 암호화 되어있지 않다.
  • HTTP 통신 방식에 암호화를 추가한 방식이 HTTPS이다.
    • HTTPS에서 사용하는 암호화를 위해 사용하는 프로토콜이 SSL/TLS이다.

SSL, TLS

SSL(Secure Sockets Layer)은 TLS(Transport Layer Security)의 전신으로 시대를 거쳐 1.0, 2.0 그리고 1996년에 3.0이 출시되었다.

이후 1999년 SSL 3.0을 기초로 한 TLS 1.0이 출시되었고 1.1, 1.2 버전을 거쳐 2018년에 TLS 1.3이 출시되었다.

SSL은 현재는 거의 사용하지 않지만, TLS와 같은 의미로 사용되고 있다.

(이하로 SSL이라고 쓰겠다.)

SSL 인증서

  • SSL은 SSL인증서가 있는 웹사이트만 실행할 수 있다.
  • SSL 인증서는 신뢰할 수 있는 기관(CA)에서 발급한다.
  • SSL인증서에는 웹사이트의 공개 키가 포함되어있다.
    • SSL인증서는 공개 키 암호화 방식(RSA)을 통해 데이터를 암호화한다.
    • 웹 서버에 비밀 키가 존재한다.

SSL 원리

  1. 서버의 공개 키/ 비밀 키를 생성한다.
  2. CA(인증된 기관)에 공개 키와 기타 정보를 전달하여 SSL인증서를 생성한다.
    • SSL인증서는 CA의 비밀 키로 암호화 된다.
  3. 서버에 인증서를 저장하고 내 서버에 접속한 클라이언트에게 인증서를 보내준다.
  4. 클라이언트(브라우저)는 인증서를 CA의 공개 키로 복호화한다.
    • 브라우저에는 CA들의 공개 키가 내장되어 있다.
    • 복호화 성공 여부를 통해 CA에서 발급한 인증서인지 확인한다.
  5. 복호화 한 인증서에 들어있는 서버의 공개 키를 이용해서 통신한다.

SSL Handshake

  1. TCP Handshaking
    • 3-way-handshake를 한다.
    • SSL 통신을 하기위해 TCP연결이 수립 되어야 한다.
  2. SSL Handshaking
    1. Client Hello (Client → Server)
      • 클라이언트가 생성한 랜덤 데이터와 클라이언트가 사용가능한 암호화 방식을 서버로 전송한다.
      • 세션 키를 전송한다
    2. Server Hello (Server → Client)
      • 서버가 생성한 랜덤 데이터와 선택한 암호화 방식을 전송한다.
      • SSL 인증서를 전송한다.
    3. 클라이언트 확인
      • SSL 인증서를 CA의 공개 키를 이용해서 복호화한다.
      • 복호화가 성공했다면 해당 인증서는 CA에서 발급한 인증서라 신뢰할 수 있다는 뜻이다.
      • 복호화하여 서버의 공개 키를 얻을 수 있다.
    4. 대칭 키 암호화를 위한 pre master secret key 생성 (Client → Server)
      • 클라이언트가 생성한 랜덤 데이터 + 서버 랜덤 데이터를 통해 특정값 생성
      • 이 값을 서버의 공개키로 암호화
      • 서버로 전송
    5. session key 생성
      • pre master secret key를 받아 서버 비밀 키로 복호화
      • 이를 통해 session key를 생성하여 클라이언트와 공유
      • session key를 사용하여 데이터를 대칭 키 암호화 방식으로 주고받음

TLS 1.3

HTTPS 패킷 분석(TLS 1.2와 TLS 1.3)

SNI 란?

SNI 차단이 뭐야? TLS 1.3은 해결책이 될 수 있을까.

인증서 체인

ROOT CA 인증서는 무엇인가?

인증서 체인 🔗

154. [Security] SSL과 인증서 구조 이해하기 : CA (Certificate Authority) 를 중심으로

HTTPS 및 SSL을 사용한 보안 | Android 개발자 | Android Developers

저작자표시 비영리

'CS > 네트워크' 카테고리의 다른 글

HTTP 버전  (0) 2023.10.22
쿠키와 세션  (0) 2021.12.26
HTTP의 Stateless  (0) 2021.12.26
네트워크의 구성요소  (0) 2021.07.19
컴퓨터 네트워크 첫 걸음  (0) 2021.07.19

HTTP란?

HTTP란 TCP/IP 네트워크 아키텍처 기준으로 보면 어플리케이션 계층에서 사용되는 프로토콜이다.

클라이언트-서버 구조에서 통신할 때 사용되며, Request와 Response가 존재한다.

HTTP 구조

HTTP의 구조는 크게 Start line + Header + Body로 구성된다.

  • Request
    • Start line
      • HTTP 메소드와, 타겟 경로, HTTP 버전이 명시된다.
    • Header
      • Host, cookie, user-agent 등의 정보가 포함된다.
    • Body
      • 서버로 보낼 정보를 담는다.
      • GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr
  • Response
    • Start line
      • HTTP 버전, 응답 상태 정보가 명시된다.
    • Header
      • 서버 정보, 날짜, 응답에 대한 정보 등이 들어간다.
    • Body
      • 서버가 응답한 리소스가 담겨있다.
      • HTML, JSON, TEXT등 여러 형식이 올 수 있다.
      • HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

HTTP 특징

HTTP/HTTPS 차이

  • HTTP는 암호화 되지 않은 데이터를 전송한다.
  • HTTP에 SSL, TLS을 결합 한 것이 HTTPS이다.
  • HTTPS 웹사이트는 인증된 기관에서 발급한 SSL/TLS 인증서를 획득해야한다.
    • SSL/TLS이란?
      • TLS는 SSL의 업그레이드 버전이다.
      • RSA암호화를 사용한다.

인증과정

  1. HTTPS 웹 사이트를 방문한다.
  2. 브라우저는 서버의 SSL 인증서를 요청한다.
  3. 서버는 public 키가 포함된 SSL 인증서를 보내준다.
  4. 브라우저가 CA의 인증서인지 검증하고, public 키를 이용해서 request를 암호화 한다.
  5. 서버에서 private key를 이용하여 메세지를 해독한다. 그리고 세션키를 암호화해서 브라우저에 전송한다.
  6. 브라우저에서 세션키를 사용해서 서버와 통신한다.

HTTP 버전

HTTP 1.0 / 1.1

  • HTTP의 초기버전(0.9라고 부름)은 한 줄로만 구성되어 있었다.
    • 리소스 요청에 대한 응답만 할 수 있다. (GET 메소드만 존재)
    • ```
    • Request
      GET /target.html
    • Response```
  • HTTP 1.0
    • 헤더가 추가되었다.
    • 버전정보와 메소드 정보를 전송한다.
      • GET, HEAD, POST 메소드
    • 상태 코드(200, 302, 404..)를 응답으로 보내줘 요청에 대한 성공/실패를 알 수 있다.
    • 헤더에 Content-Type을 명시해 HTML 이외에 데이터도 전송할 수 있음
    • 요청 하나당 커넥션을 생성하기 때문에 매번 3-way-handshake을 해야한다.
      • HTTP도 TCP 프로토콜 위에서 동작하므로, 통신을 하려면 3-way-handshake과정을 거쳐야함.
  • HTTP 1.1
    • Persistent connection 추가
      • 지정한 timeout동안 커넥션을 닫지 않는다.
      • HTTP 1.0 단점 개선
    • Pipelining 추가
      • 앞의 요청의 응답을 기다리지 않고 다음 요청을 보냄
      • 응답은 요청을 보낸 순서대로 온다.
    • Head Of Line Blocking (HOLB)
      • 앞의 요청이 너무 오래걸리면 뒤의 요청은 블럭킹 되는 문제가 있다.
    • 헤더 중복 문제

HTTP 2.0

  • HTTP 1.1 의 확장이며 성능개선을 한 프로토콜이다.
  1. 전송 방식 전환
    • HTTP 1.1 에서는 일반 텍스트에 개행문자로 헤더와 바디를 구분했지만 2.0에서는 바이너리 프레임으로 분할해서 전송한다.
    • 바이너리 형식이 전송속도와 파싱속도가 빠르고 오류 발생 가능성이 낮다.
  3. Multiplexed Streams
    • 요청의 프레임이 각 스트림을 통해 전달되고 응답을 받는다.
    • 한 커넥션 안에 여러 스트림이 존재하며, 이전 요청의 응답 여부와 상관없이 동시에 여러 요청을 처리할 수 있다.
  4. Server Push
    • 서버가 클라이언트가 요청하지 않은 리소스를 보내줄 수 있다.
      • *클라이언트에게 필요한
  5. Header Compression
    • 이전에 전송된 Header 를 table로 만들어 저장
    • 이전 Header에 포함된 내용을 제외한 새로운 내용을 허프만 인코딩으로 압축해서 전송
  • HTTP단의 HOLB는 없지만 TCP단의 HOLB는 존재

HTTP 3.0

  • QUIC(Quick UDP Internet Connection)를 기반으로 나온 HTTP의 새로운 버전
  • QUIC
    • UDP 기반의 전송 프로토콜
    • TCP의 단점을 극복하기위해 고안됨

RESTful API

출처

https://velog.io/@neity16/HTTP-HTTP-버전-별-특징#http-10

https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/

https://developer.mozilla.org/ko/docs/Web/HTTP/Overview#http_기반_api

저작자표시 비영리

'CS > 네트워크' 카테고리의 다른 글

SSL/TLS란? SNI, Intermediate-Chain  (1) 2023.10.22
쿠키와 세션  (0) 2021.12.26
HTTP의 Stateless  (0) 2021.12.26
네트워크의 구성요소  (0) 2021.07.19
컴퓨터 네트워크 첫 걸음  (0) 2021.07.19

일반적으로 웹에서 사용하는 프로토콜인 HTTP는 stateless 프로토콜이다. 따라서 로그인 상태를 유지하기 위해서는 추가적인 방법이 필요하다.

로그인 상태를 유지하기 위한 방법 중 하나인 쿠키 세션 방식을 알아보자.

그 외에, 사용자 분석과 광고, 개인화 등을 위해 쓰이기도 한다.

쿠키

클라이언트가 로그인 인증(Authorization)을 서버로 보내면, 서버는 쿠키가 있는지 확인하고, 없다면 쿠키를 생성해서 응답 요청에 담아서 보낸다.

응답 요청에서 쿠키를 받은 클라이언트는 브라우저의 쿠키 저장소에 쿠키를 저장하고, 다음 요청 때마다 쿠키를 같이 보낸다.

그러면 서버는 요청 헤더에 있는 쿠키를 보고 서버 내부에 있는 쿠키와 일치하는게 있으면 해당 사용자로 인식하게 된다. 

쿠키는 4KB이하의 String으로 이루어져 있다.

쿠키의 적용을 받는 경로, 유효기간 등을 정할 수 있다.

세션

로그인 상태 유지를 쿠키로 하고, 사용자의 아이디와 비밀번호를 쿠키에 저장한다면, 쿠키가 유출될 경우 다른 사용자가 쿠키를 사용해서 로그인 할 수도 있다.

세션은 이런 쿠키의 취약점을 보완할 수 있다.

세션은 비밀번호 같은 인증정보를 서버쪽에 저장한다. 그리고 클라이언트에게 주는 쿠키에는 사용자를 식별할 수 있는 세션 ID를 저장한다.

클라이언트는 세션 ID를 요청에 같이 보내고, 서버는 세션 ID를 통해 인증된 사용자인지 판별한다.

서버 쪽에는 유저 이름, 만료기한 등의 정보가 저장된다.

세션은 쿠키를 사용하지만, 사용자의 정보를 브라우저가 아닌 서버에서 관리한다. 클라이언트 쪽에서 관리하는 것 보다는 보안상 유리하지만, 세션을 사용자 수만큼 생성하므로, 사용자가 많아질수록 서버에 부하가 크다.

세션은 timeout이 되거나, 로그아웃하면 서버에서 삭제된다.

저작자표시 비영리

'CS > 네트워크' 카테고리의 다른 글

SSL/TLS란? SNI, Intermediate-Chain  (1) 2023.10.22
HTTP 버전  (0) 2023.10.22
HTTP의 Stateless  (0) 2021.12.26
네트워크의 구성요소  (0) 2021.07.19
컴퓨터 네트워크 첫 걸음  (0) 2021.07.19

HTTP가 뭐냐?

  • TCP/IP 네트워크 아키텍처에서 어플리케이션 계층에서 사용하는 프로토콜이다.
  • 자신이 보내고자 하는 데이터에 시작라인과 헤더 등을 붙여 목적지에 전송한다.
  • 예를들어 구글에 http를 검색하면 GET메소드, path= /search?q=http , version의 start-line과 헤더정보가 붙어 서버로 전송된다.
  • GET메소드는 보통 조회를 위해 사용하고, 포함되는 데이터는 없이 요청만 한다.
  • http프로토콜은 이런식이 된다. 
  • HTTP의 특징 중 하나로는 Stateless라는 것이다.

Stateless

  • 서버가 클라이언트의 상태를 보존하지 않는다는 뜻이다. 클라이언트의 상태라는 것은 로그인 여부나 해당 클라이언트로부터 이전에 들어온 요청 등을 말한다.
  • stateless 특징때문에 클라이언트는 한번에 요청에 모든 정보를 담아서 보내야 한다.
  • 상태를 보존하지 않기 때문에 HTTP만으로는 로그인을 유지할 수 없다. 쿠키/세션 등을 이용해서 로그인을 유지하는 방법이 있다.
  • 이렇게만 들으면 왜 stateless로 만든거지, 별로 아닌가 라고 생각할 수도 있다.
  • 하지만 stateless 특성은 큰 이점을 가진다.
    • 상태를 유지한다면, 이전에 데이터를 보냈던 해당 서버하고만 통신을 할 수 있다.
      • 같은 서비스를 제공하더라도 물리적인 서버가 여러대 존재할 수 있다.
      • 일련의 요청 중에 서버에 장애가 난다면 서버에 처음부터 다시 보내야한다.
    • 상태를 유지하지 않는다면, 특정 서버와 클라이언트에 의존하지 않고 통신할 수 있다.
      • 서버 부하에 따라 다른 서버로 요청을 보내 유동적으로 처리 할 수 있다.
      • 트래픽이 많아졌을 때, 응답 서버를 늘리기가 쉽다는 장점이 있다.
  • 단점은 요청 데이터의 크기가 크다. 따라서 매 요청마다 요청과 응답에 많은 네트워크 자원을 사용하게 된다.
저작자표시 비영리

'CS > 네트워크' 카테고리의 다른 글

SSL/TLS란? SNI, Intermediate-Chain  (1) 2023.10.22
HTTP 버전  (0) 2023.10.22
쿠키와 세션  (0) 2021.12.26
네트워크의 구성요소  (0) 2021.07.19
컴퓨터 네트워크 첫 걸음  (0) 2021.07.19

+ Recent posts

티스토리툴바