network on 오늘도 개발을 한다.

[Network] 웹소켓 알아보기 (w. WebSocket API)

Wed, 11 Dec 2024 07:54:11 +0900

서론

CS 스터디에서 11월 21일 발표한 WebSocket과 WebSocket API에 대해 정리한 문서를 블로그에 공유하고자 한다.

웹소켓(WebSocket)이란?

웹소켓(RFC 6455)
- 2011년 등장한 프로토콜
- 통제된 환경에서 신뢰할 수 없는 코드(untrusted code, 브라우저가 신뢰하지 않는 서드-파티나, 웹사이트로부터 읽어들인 코드)를 실행하는 클라이언트와, 해당 코드의 통신을 허용한 원격 호스트간의 양방향 통신 을 가능케하는 프로토콜
  - 이를통해 궁극적으로 서버와 양방향 통신이 필요한 브라우저 기반 애플리케이션이 XMLHttpRequest, <iframe>과 같은 여러 HTTP 연결에 의존하지 않는 방법을 제공하는 것이 목표
- 웹 브라우저에서 일반적으로 사용되는 출처(Origin) 기반 보안 모델을 사용
- TCP 위에 계층화 되어 있으며, 오프닝 핸드셰이크와 메시지 프레이밍으로 구성됨

등장 배경

기존의 경우, 클라이언트 - 서버 양방향 통신이 필요한 경우 업스트림 알림(클라이언트에서 서버로 전송하는 알림)을 전송하는 동시에, 서버에 새로운 값을 폴링하는 요청을 보내야 했기 때문에, HTTP 통신이 남발 되었음
이는 다음과 같은 문제를 야기함
1. 서버는 각 클라이언트에 대해 정보를 보내기 위한 연결, 정보를 받기 위한 연결을 포함하는 여러 TCP 연결을 설정해야 함
2. 각 클라이언트-서버 메시지들은 HTTP 헤더를 가지므로 오버헤드가 발생 함
3. 클라이언트 측 스크립트는 요청과 응답의 흐름을 추적하기 위해, 발신 연결(outgoing connections)에서 수신 연결(incoming connections)로의 매핑을 유지 해야 함
웹소켓은 양방향 트래픽을 위한 단일 TCP 연결을 사용해 이를 해결하고자 함
- 웹소켓 API(WSAPI)와 결합해 HTTP 폴링의 대안을 제공
기존에 존재하는 HTTP 환경의 맥락은 살리되, 처음부터 양방향 통신을 위해 고안되지 않은 HTTP를 대체할 수 있도록 설계됨
- 따라서 HTTP 포트인 80 및 443에서 동작하며 HTTP 프록시와 중개자(intermediaries)를 지원하도록 설계됨

구성

웹소켓은 연결 수립을 위한 핸드셰이크와, 이후 이뤄지는 데이터 전송 두 가지로 이루어짐
주고받는 메시지는 하나 이상의 프레임으로 이루어짐
- 프레임에 포함될 수 있는 데이터는 여러 유형이 존재하며, 한 메시지에 속하는 각 프레임은 동일한 유형의 데이터를 지님
- 데이터 유형으로는 텍스트 데이터(UTF-8), 이진 데이터 , 제어 프레임(연결 닫기와 같은 신호를 전달하기 위해 프로토콜 수준에서 사용 됨) 등이 있음

핸드셰이크

오프닝 핸드셰이크

연결을 수립하기 위한 오프닝 핸드셰이크는 HTTP 기반 서버 SW, 중개자와 호환되도록 설계됨
- 즉, HTTP 클라이언트가 사용하는 포트와 동일한 포트 사용
먼저 클라이언트 측에서 연결 수립을 위해 요청을 전송함
이때, HTTP 버전이 1.1인지, 2인지에 따라 방식이 다름
- HTTP/1.1
  - 먼저 클라이언트 측에서 GET 메서드로 HTTP Upgrade 요청을 전송
```

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
```
    - 웹소켓이 나온 2011년도에는 아직 HTTP/2(2015)가 등장하지 않았기 때문에, HTTP/1.1에 사용되는 Upgrade헤더를 사용
    - Upgrade 헤더는 HTTP/1.1에서 이미 설정된 클라이언트/서버 연결을 다른 프로토콜로 업그레이드 하기 위해 사용되며, 다음과 같은 형태로 작성됨
      Connection: upgrade Upgrade: protocol_name[/protocol_version]
      - 연결이 더 지속될 지 알아야 하므로 Connection 헤더도 함께 사용됨
- 서버는 핸드셰이크를 수신했음을 증명하기 위해, 두 가지 값을 가져와 합친 뒤 응답을 만들어 냄
  - 먼저 클라이언트 핸드셰이크 요청의 Sec-WebSocket-Key 헤더 값을 가져옴
  - 이후 문자열 형식의 GUID(전역 고유 식별자)인 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 와 연결함
    - 해당 값은 웹소켓을 이해하지 못하는 서버에서도 사용될 가능성이 아주 낮은, 웬만해서는 고유한 값임
  - 이후 연결한 문자열 값을 SHA-1 해시한 값을 서버 측 핸드셰이크로 전달함
  - 예시
    - 위에서 사용된 Sec-WebSocket-Key 헤더 값인 dGhlIHNhbXBsZSBub25jZQ==에 258EAFA5-E914-47DA-95CA-C5AB0DC85B11을 연결해 dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- C5AB0DC85B11 라는 문자열을 생성
    - 이후 이를 SHA-1 해싱해 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea 라는 값을 생성함
    - 이 값을 base64 인코딩하여 s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 라는 값으로 변환한 뒤, Sec-WebSocket-Accept 필드로 전달
- 그리고 서버에서 핸드셰이크가 완료된 경우에는 101을, 완료되지 않은 경우 이외의 값을 상태코드로 갖는 다음과 같은 형태의 응답을 반환함
```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
```
- HTTP/2
  - HTTP/2의 멀티플렉싱 특성에 의해, Upgrade, Connection과 같은 헤더나 101 응답코드와 같이 연결-전반적으로 사용되는 헤더 및 상태 코드를 허용하지 않음
  - 따라서 HTTP/2 환경에서 웹소켓을 사용하기 위한 부트스트랩이 만들어짐
    - 이는 HTTP 메서드 중 하나인 CONNECT를 확장해, 단일 HTTP/2 스트림에 웹소켓용 데이터를 전달할 수 있는 터널을 만듦
  - 확장된 CONNECT 메서드
    - CONNECT를 통해 생성한 터널에서 어떤 프로토콜을 사용할 지 나타내는 새로운 의사-헤더 필드인 :protocol을 사용
      - 해당 필드에 포함될 수 있는 값은 Hypertext Transfer Protocol (HTTP) Upgrade Token Registry에 포함된 값
    - :protocol을 포함한 요청에는 대항 URI의 :scheme, :path 의사-헤더 필드도 반드시 포함되어야 함
    - :protocol을 포함한 요청에서는 :authority 필드가 기존과 다르게 해석 됨
      - 연결한 호스트와 포트(RFC 7540 #8.3)가 아닌, 대상 URI의 권한(RFC 7540 #8.1.2.3)으로 해석됨
  - HTTP/1.1의 GET 기반 요청처럼, 클라이언트 측에서 CONNECT 메서드 요청을 통해 연결 수립을 요청
    - 해당 요청은 :protocol 필드를 반드시 포함해야 하며, websocket 값을 가져야 함
    - 목표 URI의 스키마의 맨 앞은 wss(htttp) 또는 ws(http)여야 하며, 나머지는 웹소켓 URI와 동일
    - HTTP/1.1과 달리 Upgrade, Connection, Host 헤더를 사용하지 않으며, Host 정보는 :authority의 일부로 전달됨
      - 또한, Sec-WebSocket-Key 및 Sec-WebSocket- Accept 헤더에 대한 처리가 :protocol 필드로 대체되어 이뤄지지 않음
      - 반면 Origin, Sec-WebSocket-Version, Sec-WebSocket-Protocol, Sec-WebSocket-Extensions 필드는 사용되나 HTTP/1.1과 달리 HTTP/2에서는 소문자로 작성되어야 함

클로징 핸드셰이크

연결을 종료하기 위해서는 클라이언트, 서버 두 피어 중 한 측(A)에서 제어 시퀀스(control sequence)가 포함된 제어 프레임을 전송해 클로징 핸드셰이크를 시작할 수 있음
이를 수신한 다른 피어(B)는 응답으로 닫기 프레임(close frame)을 전송함
응답을 수신한 피어(A)는 연결을 닫으며, 서로는 더 이상 데이터를 보내지도, 수신하지도 않음
이러한 별도의 클로징 핸드셰이크는, TCP 클로징 핸드셰이크(FIN/ACK)가 프록시 및 중개자에 의해 신뢰성이 낮아진다는 점을 보완하기 위해 사용됨
HTTP/2에서도 이와 유사한 형태로 스트림 클로저가 이뤄지며, TCP 수준 클로저는 HTTP/2 데이터 프레임의 END_STREAM 플래그로 표현됨

기본 데이터 프레임 구조

웹소켓 프로토콜에서 데이터 전달을 목적으로 사용되는 프레임은 위와 같은 구조로 이루어져 있음
클라이언트에서 서버로 전송되는 모든 프레임은 네트워크 중개자(ex. 프록시)의 가로채기와 같은 행위를 차단하고, 보안 관련 이유로 마스킹 이 필수적임
- 이는 웹소켓이 TLS와 함께 이뤄지는지 여부와 상관 없이 항상 수행
- 서버는 마스킹되지 않은 프레임을 수신할 경우 연결을 닫아야 함
주요 필드
- FIN
  - 현재 프레임이 메시지의 마지막 조각(Fragment)임을 나타내는 플래그
- opcode
  - 페이로드 데이터의 유형을 나타내는 값
    - %x0: 연속 프레임
    - %x1: 텍스트 프레임
    - %x2: 이진 프레임
    - %x8: 연결 종료
    - %x9: 핑 / %xA: 퐁
- masking key
  - 클라이언트에서 서버로 전송되는 모든 프레임은 이 32비트 마스킹 키로 마스킹 됨
  - 클라이언트는 매 번 허용된 32비트 값 집합에서 새로운 마스킹 키를 선택해, 프레임을 마스킹해야 함
- payload data
  - 애플리케이션 데이터와, 그와 연결된 확장 데이터로 이뤄짐
    - 확장 데이터: 오프닝 핸드셰이크때 사전 협의된 길이와 방법대로 사용되는 추가 데이터
    - 애플리케이션 데이터: 확장 데이터 다음 프레임의 나머지 공간을 차지하는 데이터

Javascript의 WebSocket

Javascript에서는 Web API 중 브라우저 API에서 제공되는 WebSocket API를 활용해 브라우저와 서버간 양방향 통신을 열 수 있음
WebSocket API는 웹소켓 연결 및 통신을 위한 두 가지 메커니즘인 WebSocket 인터페이스와 WebSocketStream 인터페이스를 제공
- WebSocket
  - 안정적이며, 대부분의 브라우저 및 서버에서 지원됨
  - 다만, 배압(Backpressure)을 지원하지 않기 때문에 애플리케이션이 처리할 수 있는 속도보다 빠르게 메시지가 도착할 경우 메시지를 버퍼링해 메모리를 가득 채우거나, CPU 사용률이 100%가 되어 애플리케이션이 정상 동작하지 않을 수 있음
- WebSocketStream
  - WebSocket의 Promise기반 대안으로, Stream API를 사용해 메시지 수신 및 전송을 처리함
    - 따라서 소켓 연결이 Stream Backpressure 자동으로 활용하여 읽기 및 쓰기 속도를 조절할 수 있고, 이를 통해 병목 현상을 방지할 수 있음
    - 그러나, WebSocketStream은 비표준으로, 크로미움 기반 브라우저(ex. Chrome, Edge, …)을 제외한 나머지 브라우저들(Safari, Firefox)은 지원하지 않고 있음

WebSocket API

연결 생성하기

웹소켓 연결을 생성하기 위해서는, WebSocket 생성자를 호출하면 됨

// WebSocket 생성자는 url, 또는 url과 protocol을 인자로 받음
// 1. new WebSocket(url)
// url은 ws, wss, http, https 중 하나의 스키마를 사용해야 함
// 또한, Node.js나 Deno같은 JS 런타임에서는 http, https를 비롯해 상대 URL을 지원하지 않음
const socket = new WebSocket("ws://somewhere.net");

// 2. new WebSocket(url, protocols)
// protocols는 웹소켓의 서브 프로토콜을 나타내는 문자열(또는 문자열 배열)
// 연결당 하나의 서브 프로토콜만 선택할 수 있으며, 허용되는 값은 `Sec-WebSocket-Protocol HTTP`에서 지정할 수 있는 값임
const socket = new WebSocket("ws://somewhere.net", ["soap"]);

생성된 WebSocket 객체의 프로퍼티를 통해 어떤 호스트와 통신하는지, 서브 프로토콜은 무엇인지를 알 수 있음
- 서브 프로토콜은 IANA의 WebSocket Subprotocol Name Registry에 포함된 것으로 사용 가능

console.log(socket.url) // 'ws://somewhere.net'
console.log(socket.protocol) // ['soap']

이벤트 처리하기

생성된 웹소켓 연결에서 발생하는 이벤트를 처리하기 위해, addEventListener를 사용하거나, WebSocket의 on이벤트이름 프로퍼티에 이벤트 리스너를 할당해줄 수 있음

open(연결 생성)

onopen: 웹소켓 연결이 열렸을 때, 발동되는 이벤트리스너

socket.onopen = function(e) {
  alert("웹소켓 연결이 생성되었습니다. ");
  socket.send("Hello there!");
};

이벤트리스너에게 전달되는 Event는 일반 Event임

message(데이터 수신)

onmessage: 웹소켓 연결을 통해 데이터가 수신될 때, 발동되는 이벤트리스너

socket.onmessage = function(e) {
  alert("서버로부터 다음과 같은 메시지가 수신되었습니다.");
  alert(`메시지: ${e.data}`);
};

MessageEvent: message 이벤트리스너에게 전달되는 이벤트
- data: 메시지 발신자(emitter)가 보내온 데이터. WebSocket.binaryType에 따라 data의 유형이 달라짐
  - 메시지 유형이 text인 경우, data는 문자열 값
  - 메시지 유형이 binary인 경우, data의 유형은 WebSocket.binaryType에 따라 달라짐
    - binaryType이 arraybuffer인 경우, ArrayBuffer
    - binaryType이 blob인 경우, Blob
- origin: 메시지 발신자의 출처를 나타내는 문자열

error(에러 발생)

onerror: 데이터가 안보내진다거나 하는 오류로 웹소켓 연결이 닫힐 때, 발동되는 이벤트리스너

socket.onerror = function(error) {
  alert(`다음과 같은 에러가 발생했습니다. ${error}`);
};

이벤트리스너에게 전달되는 Event는 일반 Event임

close(연결 종료)

onclose: 웹소켓 연결이 닫힐 때, 발동되는 이벤트리스너

socket.onclose = function(e) {
  if (e.wasClean) {
	// 연결이 정상적으로 종료된 경우
    alert(`연결이 정상적으로 종료되었습니다(code=${event.code} reason=${event.reason})`);
  } else {
	// 프로세스가 죽거나, 네트워크 장애와 같은 이유로 연결이 닫힌 경우
    alert('커넥션이 죽었습니다.');
  }
};

CloseEvent: close 이벤트리스너에게 전달되는 이벤트
- code: 1000~4999 사이의 웹소켓 연결 종료 코드 를 나타내는 unsigned short 값
- reason: 서버가 연결을 종료한 이유를 나타내는 문자열
- wasClean: 연결이 정상적으로 닫혔는지 여부를 나타내는 부울 값

메시지 전송과 연결 닫기

WebSocket 객체에는 데이터를 전송할 수 있는 send() 메서드와 연결을 종료할 수 있는 close 메서드가 존재

메시지 전송

WebSocket.send() 메서드를 통해 사용자가 서버로 데이터를 전송할 수 있음
- 정확히는, 전송할 데이터를 대기열에 넣고, bufferedAmount 값을 늘림
- 만약 데이터를 전송할 수 없는 경우, 소켓은 자동으로 닫힘
- 연결이 CONNECTING 상태라면 브라우저가 예외를 던지고, CLOSING 또는 CLOSED 상태라면 데이터를 자동으로 삭제함
send()는 data라는 하나의 인자만 받으며, data의 타입은 다음 중 하나여야 함
- string
  - UTF-8로 인코딩되어 버퍼에 추가되며, 이를 나타내는데 필요한 바이트 수만큼 bufferedAmount가 증가함
- ArrayBuffer
  - 타입이 지정된 배열 객체(typed array object)가 사용하는 바이너리 데이터를 전송할 수 있으며, 이는 버퍼에 추가되고 해당 바이너리 데이터 바이트 수 만큼 bufferedAmount가 증가함
    - ArrayBuffer는 다른 언어에서 Byte Array라고 일컫는, byte들의 배열임
      - 내용을 직접 조작할 순 없으나, 후술할 typed Array 객체나 DataView 객체를 통해 버퍼의 내용을 읽고 쓸 수 있음
- Blob
  - 불변 로우 데이터로 이뤄진, 파일과 유사한 객체인 Blob의 로우 데이터가 버퍼에 추가되며(이때, Blob.type은 무시됨), bufferedAmount는 해당 로우 데이터의 바이트 크기만큼 증가함
- TypedArray/DataView
  - Javascript Typed Array(ex. Int8Array, Int16Array, ...)가 가지고 있는 바이너리 데이터들이 버퍼에 추가되며, 필요한 바이트 수만큼 bufferedAmount가 증가함
  - 또는, 이진 ArrayBuffer에서 여러 넘버 타입을 읽고 쓸 수 있게 해주는 저수준 인터페이스인 DataView도 인자로 사용할 수 있음

연결 닫기

연결 피어 중 한 측에서 연결을 닫고 싶을때, WebSocket.close() 메서드를 통해 연결을 종료할 수 있음
- 만약 클로징 핸드셰이크 전에 메시지를 보내거나, 여전히 보내고 있다면 이러한 메시지들이 모두 전송된 뒤에 핸드셰이크가 시작됨
close()는 옵셔널 인자인 code와 reason 인자를 받음
- code
  - 종료 이유를 나타내는 웹소켓 연결 종료 코드 정수값
  - 값을 지정하지 않으면, 일반 종료의 경우 1000, 이외 연결 종료 사유가 있는 경우 그에 해당하는 1001 ~ 1015 범위의 코드 값으로 설정됨
  - code 값이 설정되면, reason 값도 설정되어야 함
- reason
  - 사용자 지정 웹소켓 연결 종료 이유를 제공하는 문자열로, UTF-8로 인코딩되어야 하고 123바이트를 넘지 않아야 함

예시

WebSockets Example - JSFiddle - Code Playground
- 해당 예제에서 주소를 ws에서 wss로 바꿔주면 정상 동작함

[Network] TCP와 UDP 알아보기 (w. 흐름 제어, 혼잡 제어, CongWin, HTTP/3)

Fri, 01 Nov 2024 18:18:16 +0900

서론

CS 스터디에서 10월 28일 발표한 TCP & UDP에 대해 정리한 문서를 블로그에 공유하고자 한다.

TCP와 UDP에 대하여

TCP와 UDP는 네트워크 계층 중 전송 계층(transport-layer)에서 사용되는 프로토콜
- 전송 계층
  - 프로세스 간 논리적 통신(logical communication)이 이뤄지는 계층
  - 네트워크 계층의 서비스들에 의존하고, 이들을 강화시키는 계층
  - 보내려는 메시지를 전송 계층의 규격에 맞게 분할 후, 해야할 일을 헤더로 부착해 보내는 과정을 거침

TCP

요약

신뢰성(reliable)
순서에 맞게 전송하고자 함(in-order)
혼잡 제어, 흐름 제어, 연결 설정과 같은 기능 제공

주요 특징

1대1 통신(unicast)
신뢰할 수 있고, 순차적인 바이트스트림
- 메시지 바운더리 없음 (전송되는 두 메시지 사이의 구분 이 없음)
- 송신 번호, ACK 번호를 사용
파이프라인 사용
- TCP 혼잡, 흐름 제어를 위한 window size를 설정
전이중 데이터
- 동일한 연결 상에서 양방향 통신
- 최대 세그먼트 크기(MSS)
연결지향적 통신
- 데이터 교환 전, 핸드셰이킹(제어 메시지 교환)으로 송신자-수신자 상태 초기화
흐름 제어
- 송신자가 수신자를 압도(overwhelm)하지 않음

RTT(Round Trip Time, 왕복 시간)

TCP의 효율적인 통신을 위해, 지정된 시간 내에 ACK 신호나 세그먼트를 수신하지 못한 경우, 연결 시간 초과(timeout)로 처리하고 연결을 종료해야 함.

이때, TCP timeout 시간은 RTT보다 길어야 함
- 하지만, RTT는 편차가 있을 수 있음
- 너무 짧게 잡는다면, 재전송이 자주 발생함
- 너무 길게 잡는다면, 세그먼트 손실에 대해 느리게 반응하게 됨
이때, RTT의 편차 등을 어떻게 측정해야 할까?
- SampleRTT
  - 세그먼트 전송 후, ACK 수신까지 측정된 시간 (재전송 무시)
  - 다만 SampleRTT 역시 다양할 수 있으므로, 이들의 여러 최근 측정값을 평균내어 사용
RTT의 기준?
- 만약 ACK 수신 이전, 여러 번의 세그먼트 전송이 발생한 경우 가장 처음 보낸 세그먼트를 기준으로 함
- 만약 동일한 세그먼트가 재전송 된 경우, RTT 측정에 포함하지 않음
  - 처음 보낸 세그먼트에 대한 ACK 인지, 재전송된 세그먼트에 대한 ACK인지 구분할 수 없기 때문

신뢰할 수 있는 데이터 전송

응용, 전송, 링크 계층에서 신뢰성은 매우 중요한 개념으로, 각 계층마다 신뢰성 유지를 위해 데이터를 체크
- 신뢰성: 비트 에러, 패킷 손실 없이 한 번만 전송하는 것

TCP에서의 RDT

TCP는 RDT(Reliable Data Transfer, 신뢰성 있는 데이터 전송) 서비스를 IP의 신뢰성 없는 서비스 위에 구축함
- 파이프라인화된 세그먼트 (연속으로 전송할 수 있음)
- 누적 ACK (GoBackN과 유사)
- 단일 재전송 타이머 (데이터 보낸 시간 != timeout 시간 일 수 있음)
재전송은 다음 두 경우 발생
- timeout 이벤트
  - timeout이 발생한 경우, 이를 일으킨 세그먼트를 재전송
  - 타이머 재시작
- 중복된 ACK
  - 이전에 ACK되지 않은 세그먼트를 ACK하는 경우
  - 어떤 패킷이 ACK되었다고 알려져있는지 갱신
  - ACK되지 않은 세그먼트 아직 있으면 타이머 시작

흐름 제어

흐름 제어: 빠른 발신자가 너무 많이, 너무 빨리 전송해 느린 수신자 버퍼가 넘치지 않도록(압도하지 않도록) 함
수신자는 TCP 헤더에 윈도우 크기(rwnd)를 포함시켜, 사용 가능한 버퍼 공간을 명시함
- 소켓 옵션을 통해 설정된 수신자 버퍼(RcvBuffer)크기 값으로, 보통 4096 byte가 디폴트
- 대부분의 운영체제에서 이 크기를 자동 조정함
발신자는 수신자의 윈도우 크기 만큼만 ACK되지 않은(in-flight) 데이터를 보낼 수 있음
- 이는 수신자 버퍼가 넘치지 않도록 보장

Stop-and-wait

가장 간단한 형태의 흐름 제어 기법
발신자가 하나의 패킷을 보낸 뒤, 수신자의 응답이 올 때까지 기다림
- ACK 를 수신하거나, 타임아웃이 발생하면 다시 패킷 전송

Go-back-N

send_base: 보낸 패킷 nextseqnum: 보낼 예정인 패킷

N개의 ACK되지 않은 패킷을 파이프라인을 통해 전송
수신자는 누적 ACK(cumulative ACK)만 전송
발신자는 가장 오래된 ACK되지 않은 패킷에 대한 타이머 갖고 있음
- 타임아웃 발생시, 모든 ACK되지 않은 패킷들을 재전송
  - 즉, 가장 마지막으로 ACK 받은 시퀀스 번호로 돌아가 재전송

Selective Repeat

N개의 ACK되지 않은 패킷을 파이프라인을 통해 전송
수신자는 각각의 패킷에 대한 ACK를 전송
발신자는 각 패킷에 대한 타이머를 갖고있음
- 타임아웃 발생시, 해당 패킷만 재전송
수신자는 순서를 지켜(in-order) 상위 계층에 패킷들을 전달하기 위해, 버퍼 사용
- 문제 생긴 패킷 다음의 패킷들을 버퍼에 저장, 또는 순서에 맞지않는 패킷들 저장
- 이후, 문제 생긴 패킷을 재전송받고, 일정 갯수의 패킷이 모이면 상위 계층으로 전달
참고
- Selective Repeat Protocol : Selective Repeat 흐름을 테스트해볼 수 있는 사이트

혼잡 제어

발신자가 혼잡함을 인식하는 기준
- 손실 이벤트(loss event): 타임아웃 또는 3번의 중복된 ACK
TCP 발신자는 손실 이벤트 발생시, 혼잡에 대응하기 위해 혼잡 윈도우(Congestion Window, CongWin)의 크기를 조절해 대응
혼잡 제어를 위해 AIMD, slow start, conservative after timeout events 3가지 메커니즘 존재

AIMD

Additive Increase Multiplicative Decrease의 약어
혼잡 윈도우를 혼잡이 감지되지 않을때는 선형적으로 증가시키다, 혼잡이 감지되면 기하급수적으로 감소시키는 방식
- 손실이 감지될 때까지, 매 RTT마다 cwnd를 1 MSS씩 증가
- 손실이 발생하면, cwnd를 절반으로 줄임
즉, cwnd는 인식된 네트워크 혼잡 정도를 나타내는 함수라고 할 수 있음
TCP 전송 속도 $rate \approx {cwnd \over RTT} bytes/sec$

Slow Start

연결 시작 이후, 손실 이벤트 발생 전까지 속도를 기하급수적으로 증가시키는 방식
- 초기 cwnd = 1 MSS
- 매 RTT마다 cwnd는 2배씩 증가
  - 정확히는 모든 ACK 수신마다 cwnd를 2배로 증가시킴
- 시작 값이 1이라 Slow Start라는 이름이 붙었으며, 증가 속도는 빠름

Conservative after timeout events(타임아웃 발생 후 보수적으로)

타임아웃으로 손실을 인식
- cwnd는 1로 세팅됨
- 이후 cwnd가 기하급수적으로 임계값(threshold)까지 증가한 뒤, 선형적으로 증가
3개의 중복 ACK로 손실을 인식 : TCP RENO
- 중복 ACK는 네트워크가 아직 세그먼트들을 전달할 수 있음을 나타냄
- cwnd를 절반으로 줄인 뒤, 선형적으로 증가
타임아웃 또는 3개의 중복 ACK 발생시 손실 인식 : TCP Tahoe
- 인식시 cwnd를 1로 설정

요약

cwnd가 임계값보다 낮을때, 발신자는 Slow Start 단계로, 윈도우가 기하급수적으로 증가
cwnd가 임계값 이상이면, 발신자는 혼잡 회피 단계로, 윈도우는 선형적으로 증가
3개의 중복 ACK 발생시, 임계값은 cwnd/2로 설정되고, cwnd는 임계값으로 설정됨
타임아웃 발생시, 임계값은 cwnd/2로 설정되고, cwnd는 1 MSS로 설정됨

TCP 세그먼트 구조

TCP 세그먼트는 다음으로 이뤄져있음
- 송신 포트
- 수신 포트
- 순서 번호 (Sequence Number, 현재 세그먼트의 가장 앞 바이트 번호)
- ACK 번호 (마지막으로 수신한 데이터 바이트 다음의 번호)
- 헤더 길이(4 bits)
- 예약된 공간(6 bits)
- TCP 제어 플래그 참고 - TCP 제어 플래그
  - URG : Urgent Pointer필드에 값이 채워져있음을 알림
  - ACK: ACK 번호 필드에 값이 세팅되어있음을 알림
    - SYN 세그먼트 전송 이후 모든 세그먼트에 항상 이 비트가 1로 설정됨
  - PSH: Push the Data, 버퍼링된 데이터를 가능한 빨리 상위 계층 응용프로그램에 전달할 것
    - 수신 측은 버퍼가 차기를 기다리지 않고 버퍼링된 데이터들 응용프로그램에전달
  - PST: 연결확립(ESTABLISHED)된 회선에 강제 리셋 요청
    - LISTEN,SYN_RCVD 상태라면 LISTEN 상태로, 그외의 경우 연결 끊고 CLOSED 상태로
  - SYN: 연결설정을 위해 순서 번호를 동기화
    - SYN=1, ACK=0 -> SYN 세그먼트(연결 요청)
    - SYN=1, ACK=1 -> SYN+ACK 세그먼트(연결 허락)
    - ACK=1 -> ACK 세그먼트(연결 설정)
  - FIN: 연결 종료
    - FIN=1 -> FIN 세그먼트 (종결 요청)
    - FIN=1, ACK=1 -> FIN+ACK 세그먼트 (종결 응답)
- 윈도우 (수신자가 수락할 의향이 있는 바이트 수)
- 체크섬 (헤더+텍스트를 16비트 word들로 분할해, 이를 16비트 1의 보수합으로 누계한 다음, 최종 결과 값의 1의 보수를 구한 것)
- 긴급 포인터(Urgent Pointer)(긴급 포인터의 현재 값을 순서 번호의 오프셋으로 전달하는 값. 긴급 포인터는 긴급 데이터 다음 바이트의 순서 번호를 가리킴)
- 옵션 (MSS 옵션 협상, 윈도우 크기 확장, 선택확인응답(SACK) 등의 옵션 데이터를 포함할 수 있음)

UDP

요약

신뢰할 수 없음(unreliable)
순서 지키지 않음(unordered)
어떤것도 보장하지 않는(best-effort) IP의 기본적인(bare bones) 확장
- 즉, 어떠한 기능도 지원하지 않음
지연 보장, 대역폭 보장과 같은 서비스 지원되지 않음
- 모든 데이터들이 동급이라는 전제가 있어, ‘어떤 파일을 빨리 보내야 한다’ 이런 개념이 존재하지 않음

주요 특징

“best effort"한 서비스 제공

따라서 UDP Segment는

손실 가능(송신자는 전송 이후 신경쓰지 않음)
비순차적으로 전달됨

`connectionless`

UDP 송신자-수신자 간 핸드셰이킹 없음
각 UDP Segment는 다른 Segmeent들과는 독립적으로 처리됨

신뢰성 없음

따라서 UDP 상에서 신뢰성 있는 전송이 필요하다면, 응용 계층에서 이를 구현해야 함

장점

연결 조율 과정이 없음
- 따라서 이로인한 딜레이 X
단순함
- 송-수신자 간 연결 상태가 존재하지 않음
작은 헤더 사이즈
혼잡 제어 없음
- 원하는 만큼 빠르게 전송할 수 있음

UDP 세그먼트 구조

UDP 헤더는 출발 포트, 도착 포트, 길이(헤더와 세그먼트를 포함한), 체크섬으로 이뤄짐

UDP 체크섬

전송된 세그먼트에서 에러(ex. 반전된 비트(flipped bits))를 감지하기 위해 사용되는 데이터 블록
송신자
- 헤더 필드를 포함한 세그먼트 내용을 16 bit 정수 시퀀스로 처리
- 체크섬: 세그먼트 내용의 1의 보수(모든 비트를 반전시킨 값)
- 송신자는 체크섬 값을 UDP 체크섬 필드로 전달
수신자
- 수신한 세그먼트의 체크섬을 계산
- 만약 계산한 값이 체크섬 필드의 값과
  - 같다면, 에러가 검출되지 않은 것
  - 다르면, 에러가 검출된 것

사용처

UDP는 위와 같은 특징 때문에 주로 다음의 용도로 사용됨

멀티미디어 스트리밍 애플리케이션
- 손실을 허용하고, 속도에 민감함
DNS
SNMP

Checksum이란?

체크섬?
- 전송된 세그먼트에서 에러(ex. 반전된 비트(flipped bits))를 감지 하기 위해 사용되는 데이터 블록
  - 헤더 필드를 포함한 세그먼트 내용을 16 bit 정수 시퀀스로 분해한 뒤, 1의 보수로 합을 누적하여 구함

TCP와 UDP 중 어느 프로토콜이 Checksum을 수행하는가?

TCP, UDP 모두 Checksum을 수행할 수 있다
- 다만, UDP의 경우 IPv4에서는 선택적이고 IPv6에서는 필수

Checksum을 통해 오류를 정정할 수 있는가?

checksum을 이용한 오류 정정은 불가능
- 단순히 각 16비트 word들의 1의 보수 합이기 때문에 원래 값이 무엇이었는지 유추하기 힘듦
- 따라서 자동반복요청(ARQ) 기법을 사용하거나, Hamming Code, Reed–Solomon code등 오류 정정 코드를 사용하는 전진오류수정(FEC) 기법을 사용해 오류를 정정해야 함
  - 이러한 기법들은 데이터링크 계층에서 수행됨

TCP가 신뢰성을 보장하는 방법

TCP에서는 신뢰성을 보장하기 위해 다음과 같은 서비스 제공
- 파이프라인화된 세그먼트 (연속으로 전송할 수 있음)
- 누적 ACK (Go-Back-N과 유사)
- 단일 재전송 타이머 (데이터 보낸 시간 != timeout 시간 일 수 있어 타이머 사용)
위 서비스를 통해 비트 에러, 패킷 손실이 일어난 데이터를 감지하고 재전송을 요청함.
이때, 재전송은 다음 두 경우 발생
- timeout 이벤트
  - timeout이 발생한 경우, 이를 일으킨 세그먼트를 재전송
  - 타이머 재시작
- 중복된 ACK
  - 이전에 ACK되지 않은 세그먼트를 ACK하는 경우
  - 무엇이 ACK되었다고 알려져있는지 갱신
  - ACK되지 않은 세그먼트 아직 있으면 타이머 시작

TCP의 혼잡 제어 처리 방법

TCP에서는 혼잡 제어를 위해 AIMD, slow start, conservative after timeout events 3가지 메커니즘 존재
- 발신자가 혼잡함을 인식하는 기준
  - 손실 이벤트(loss event): 타임아웃 또는 3번의 중복된 ACK
- TCP 발신자는 손실 이벤트 발생시, 혼잡에 대응하기 위해 혼잡 윈도우(Congestion Window, CongWin)의 크기를 조절해 대응

AIMD

Additive Increase Multiplicative Decrease의 약어
혼잡 윈도우를 혼잡이 감지되지 않을때는 선형적으로 증가시키다, 혼잡이 감지되면 기하급수적으로 감소시키는 방식
- 손실이 감지될 때까지, 매 RTT마다 cwnd를 1 MSS씩 증가
- 손실이 발생하면, cwnd를 절반으로 줄임
즉, cwnd는 인식된 네트워크 혼잡 정도를 나타내는 함수라고 할 수 있음
TCP 전송 속도 $rate \approx {cwnd \over RTT} bytes/sec$

Slow Start

연결 시작 이후, 손실 이벤트 발생 전까지 속도를 기하급수적으로 증가시키는 방식
- 초기 cwnd = 1 MSS
- 매 RTT마다 cwnd는 2배씩 증가
  - 정확히는 모든 ACK 수신마다 cwnd를 2배로 증가시킴
- 시작 값이 1이라 Slow Start라는 이름이 붙었으며, 증가 속도는 빠름

Conservative after timeout events(타임아웃 발생 후 보수적으로)

타임아웃으로 손실을 인식
- cwnd는 1로 세팅됨
- 이후 cwnd가 기하급수적으로 임계값(threshold)까지 증가한 뒤, 선형적으로 증가
3개의 중복 ACK로 손실을 인식 : TCP RENO
- 중복 ACK는 네트워크가 아직 세그먼트들을 전달할 수 있음을 나타냄
- cwnd를 절반으로 줄인 뒤, 선형적으로 증가
타임아웃 또는 3개의 중복 ACK 발생시 손실 인식 : TCP Tahoe
- 인식시 cwnd를 1로 설정

왜 HTTP는 TCP를 사용하는가?

TCP가 신뢰성 을 제공하기 때문
- HTTP는 신뢰할 수 있는 전송(reliable transport)을 전제로하는 프로토콜임
- 따라서 이를 기본적으로 제공하는 TCP를 선택
  - 만약 신뢰성이 제공되지 않아 패킷들의 순서가 뒤죽박죽이 되거나, 누락될 경우 웹사이트를 이루는 요소들이 올바르게 배치되지 않거나 텍스트, 이미지 등의 정보가 누락될 수 있음

왜 HTTP/3 에서는 UDP를 사용하는가?

HTTP/3는 TCP의 고질적인 문제점을 해결하고자 UDP를 채용
- TCP로 인해 발생하는 문제
  - HOL Blocking
    - TCP의 신뢰성때문에, 한 스트림에서 데이터 손실 발생시, 다른 데이터 스트림들은 손실된 데이터 재전송될 때까지 차단됨
  - 연결 설정으로 인한 지연
    - TCP가 연결 설정할 때 거치는 3-way handshake 과정과 보안을 위한 TLS Handshake 때문에 두 번의 지연 발생
      - 반면 UDP(정확히는 QUIC)는 최초 연결 설정시 연결에 필요한 정보 + 데이터를 함께 전송해 1-RTT로 지연을 줄임
  - 패킷 암호화 불가능
    - TCP 프로토콜 헤더는 암호화 및 인증되지 않아, 중개자에 의한 변조/인젝션/도청에 취약
      - 반면 QUIC은 일부 메시지를 제외한 모든 패킷 헤더와 메시지 본문이 암호화 됨
  - 연결 요소 변경시 연결 재설정
    - TCP 연결은 출발지 IP, 출발지 포트, 도착지 IP, 도착지 포트 4가지를 기반
      - 하나라도 변경될 경우 연결 다시 설정해야 함
    - 반면 QUIC은 연결 ID를 기반으로해, 이 값이 변경되지 않는 이상 연결 계속 유지

브라우저는 어떤 서버가 TCP를 쓰는지 UDP를 쓰는지 어떻게 알 수 있는가?

연결 시도 과정에서 알 수 있음
- 먼저 브라우저는 TCP로 443번(HTTPS), 또는 80번(HTTP) 포트로 연결 시도
  - HTTP/1.1 또는 HTTP/2로 연결을 설정하기 위함
- 만약 서버가 HTTP/3를 지원하는 경우, h3 ALPN 토큰을 사용해 Alt-Svc HTTP 응답 헤더 필드를 사용하거나, HTTP/2 ALTSVC 프레임을 통해 동등한 HTTP/3 엔드포인트를 지원함을 알림
  - Alt-Svc : 향후 요청에 대해 다른 네트워크 위치(대체 서비스)역시 현재 요청의 오리진처럼 정당한 응답을 받을 수 있음을 알림.
- Alt-Svc 필드의 값을 활용해 h3 키에 해당하는 값의 UDP 포트로 연결 시도
  - 만약 h3=":443"인 경우, UDP 443 포트로 QUIC 연결 시도

참고

전공 강의 자료
- “Computer Networking: A Top Down Approach - 7th Edition”, Jim Kurose, Keith RossPearson. April 2016
W6.Transport_Layer.pdf - SNU
TRANSMISSION CONTROL PROTOCOL - ietf.org/rfc/rfc793.txt
RFC 9293 - Transmission Control Protocol (TCP)
Reliable Data Transfer over UDP - Simon Fraser University
RFC 7838 - HTTP Alternative Services
TCP 제어 플래그 - ktworld
TCP Header- ktworld
TCP 혼잡제어 - ktworld
Fall ’20 COSE322-00 System Programming TCP in Linux - korea univ
How is TCP & UDP Checksum Calculated?
The TCP/IP Guide - TCP Checksum Calculation and the TCP “Pseudo Header”

[Network] JWT 알아보기 (w. JWE, JWS)

Thu, 10 Oct 2024 16:46:55 +0900

서론

CS 스터디에서 10월 8일 발표한 JWT에 대해 정리한 문서를 블로그에 공유하고자 한다.

JWT 인증 방식이 무엇인가요?

JWT 인증 방식이란, 두 당사자 간 전송할 클레임(claim) 을 나타내는 JWT(JSON 웹 토큰)을 통해 사용자를 인증하는 방식을 말합니다.
JWT는 공간이 제약된 환경, 예를 들어 HTTP Authorization 헤더, URI 쿼리 매개변수와 같은 환경에서 클레임들을 주고 받을 수 있도록 간결화하는 것이 목적입니다.

클레임: 키-값 쌍으로 이뤄진 데이터

JWT?

JWT(JSON Web Token)는 당사자 간 정보를 JSON 객체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 개방형 표준(RFC 7519)입니다.
JWT는 정보(클레임 집합)를 선택적 서명(JWS 구조로 인코딩)/암호화(JWE 구조로 인코딩)한 JSON 객체라고 할 수 있으며, 이 JSON 객체는 0개 이상의 클레임을 가질 수 있습니다.

출처: How to Sign and Validate JSON Web Tokens – JWT Tutorial (freecodecamp.org)

주로 인증 과정에서 사용자가 자격 증명을 통해 로그인에 성공하면 JWT가 반환되며, 사용자가 보호된 경로/리소스에 접근할 경우 Bearer 스키마를 통해 Authorization 헤더에 JWT를 첨부해 요청해야 합니다.
즉, 다음과 같은 형태를 띄어야 합니다.

Authorization: Bearer <token>

JWE(JSON Web Encryption) RFC 7516

출처: Using JSON Web Encryption (JWE) - DZone

JWT 내용을 디지털 방식으로 암호화 함.
- 따라서 무결성 검증 및 콘텐츠 보호에 사용할 수 있음.
- 또한 인증된 암호화(AUtehmticated Encryption)를 통해 평문의 기밀성과 무결성, JWE 보호 헤더(JWE Protected Header)의 무결성을 보장.
본질적으로 콘텐츠를 암호화 하므로, `HTTP 상에서 사용할 수 있음.
일반적인 구조

<Base64URL 인코딩 된 UTF8 인코딩 형태의 JWE Protected Header>.<Base64URL 인코딩 된 JWE Encrypted Key>.<Base64URL 인코딩 된 JWE Initialization Vector>.<Base64URL 인코딩 된 JWE Ciphertext>.<Base64URL 인코딩 된 JWE Authentication Tag>

과정
- JWT Protected Header를 선언한다.
  - 헤더는 다음 두 가지를 갖고있다.
  - alg: 콘텐츠 암호화 키(Content Encryption Key)를 어떤 알고리즘을 사용해 암호화할지 나타냄.
  - enc: 어떤 알고리즘을 사용해 인증된 암호화(AUtehmticated Encryption)를 수행할지 지 나타냄.
    - 인증된 암호화는 평문에 대해 수행되어, 암호화된 텍스트(ciphertext)와 인증 태그(Authentication Tag)를 생성함.
  - 이후 이를 UTF-8로 인코딩 한 뒤, Base64URL로 인코딩 한다.
- 랜덤한 CEK(콘텐츠 암호화 키)를 생성한다.
- CEK를 RSAES-OAEP 알고리즘을 사용해 수신자의 공개키로 암호화하여, JWE Encrypted Key를 생성한 뒤, Base64URL 인코딩을 수행한다.
- 랜덤한 JWE Initialization Vector를 생성한 뒤, Base64URL 인코딩을 수행한다.
- 평문에 AES GCM 알고리즘을 사용해 인증된 암호화를 수행한다.
  - CEK를 암호화 키로 사용하며, 추가로 JWE Initialization Vector, AAD 역시 사용한다.
  - 이를 통해 Ciphertext(암호문)와 128비트 JWE Authentication Tag를 만들어내고, 이들에 대해 Base64URL 인코딩을 수행한다.

JWS(JSON Web Signature) RFC 7515

출처: Components of JWTs Explained (fusionauth.io)

디지털 서명을 통해 발신자-수신자 간 전송되는 JWT 내용이 변조되지 않음을 보장하는 JWT
일반적으로 JWT 인증에 사용되는 형태는 JWS라고 할 수 있음
특징
- 내용(클레임)은 타인도 읽을 수 있음.
  - 따라서 비밀번호와 같은 민감 데이터를 전송하는데 사용해서는 안 됨.
- 본질적으로 타인이 데이터를 읽는 것을 방지하지 않으므로, HTTPS 또는 SSL를 통해 전송됨.
- 비밀(secret)(HMAC 알고리즘) 또는 공개-개인 키 쌍(RSA, ECDSA 알고리즘)을 사용해 서명할 수 있음.
일반적인 구조

<Base64URL 인코딩된 헤더>.<Base64URL 인코딩된 페이로드>.<Base64URL 인코딩된 시그니처>

JWT의 구조

JWT는 점(.)으로 구분된 세 가지 부분으로 구성되어 있음 즉, <header>.<payload>.<signature>와 같은 형태

header
- 일반적으로 두 부분을 갖는 JSON 객체로, Base64URL 인코딩을 거쳐 JWT의 첫 번째 부분을 맡음.
  - typ: 토큰의 유형
  - alg: 사용된 서명 알고리즘
Payload
- 0개 이상의 클레임을 포함하는 JSON 객체로, 엔티티(주로 사용자)와 추가적인 데이터로 이뤄짐.
- 클레임은 registered, public, private 세 가지 종류가 있음.
  - registered
    - 미리 정의된 클레임 셋으로, 필수는 아니지만 권장되는 사항으로 유용하며 상호 운용 가능함.
      - iss(issuer): JWT를 발급한 주체를 식별
      - sub(subject): JWT의 주제가 되는 주체(인증가능한 엔티티).
        
        JWT의 클레임은 일반적으로 subject에 대한 진술임.
        
        또한, 발행자의 컨텍스트상에서 또는 전역적으로 subject는 고유해야함.
      - aud(Audience): JWT가 의도하는 수신자를 식별
        
        즉, JWT를 처리하는 각 주체들은 aud 클레임 값으로 자신을 식별해야 함.
      - exp(expiration time): JWT 처리가 허용되어서는 안되는 만료 시간(또는 그 이후)
      - nbf(not before): JWT 처리가 허용되어서는 안되는 이전 시간
      - iat(issued at): JWT가 발행된 시점을 식별
      - jti(jwt id): JWT의 고유 식별자
  - public
    - JWT를 사용하는 측에서 마음대로 정의할 수 있음
    - 다만 충돌 방지를 위해선 IANA JSON Web Token Registry에 정의되어 있거나, 충돌 방지 네임스페이스가 포함된 URI로 정의해야 함.
  - private
    - 사용자 지정 클레임으로, 사용에 동의한 당사자 간에 정보 공유하기 위해 만듦
signature
- Base64 인코딩된 헤더, 페이로드, 비밀을 가져와 헤더에 지정된 알고리즘으로 서명한 값
  - 예를 들어, HMAC SHA256 알고리즘으로 서명하는 경우 다음과 같음
    - HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
- 서명은 메시지가 도중에 변경되진 않았는지 확인하는데 사용
  - 개인 키로 서명된 토큰은 JWT 발신자가 본인이 맞는지 확인할 수도 있음

JWT의 장점

SSO와 같은 시스템에서 주로 사용되는 또 다른 인증 포맷인 SAML 토큰 대비

더 간결하다

JSON은 XML보다 장황하지 않아 웬만한 경우 JWT가 SAML 토큰보다 작음.
- SAML(Security Assertion Markup Language): SSO와 같은 인증 방식에서 사용되는 포맷으로, XML을 기반으로 인증 대상자가 누구인지 알려주는 표준화된 방법
  - SAML | Okta Identity Korea
  - SAML이란? | SAML 인증이 작동하는 방식 | Cloudflare
따라서 HTML 및 HTTP환경에서 전달하기 용이함

더 안전하다

JWT는 서명을 위해 X.509 인증서 형식의 공개-개인키 쌍을 사용하거나, HMAC 알고리즘을 사용해 공유된 비밀로 대칭적 서명이 가능
SAML 토큰은 JWT와 같이 공개-개인키 쌍을 사용할 수 있지만, 취약점없이 XML 디지털 서명을 통해 XML에 서명하는것은 JSON 서명의 단순성 에 비하면 매우 어려움

더 대중적이다

JSON parser는 JSON이 객체에 직접 매핑되므로 대부분의 프로그래밍 언어에서 일반적임
반면 XML은 자연스러운 문서-to-객체 매핑이 없음
- 따라서 SAML assertion 대비 작업이 더 쉬움

Signature는 어떻게 만들어지나요?

Base64 인코딩된 헤더, 페이로드, 비밀을 가져와 헤더에 지정된 알고리즘으로 signature를 만듦
- 예를 들어, HMAC SHA256 알고리즘으로 서명하는 경우 다음과 같음
  - HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

만약 Access Token이 탈취되면, 어떻게 대응할 수 있을까요? / 반대로 Refresh Token이 탈취되면, 어떻게 대응해야 할까요?

토큰이 탈취 당한 경우, 아래와 같은 방법들을 통해 토큰을 무효화해야합니다.

토큰 블랙리스트

유효하지 않은 것으로 간주되어야 할 토큰의 jti 클레임, 또는 사용자 id와 같은 식별자를 서버측 블랙리스트에서 관리하는 방법
API 엔드포인트에 토큰이 제시되면, 서버는 블랙리스트에 포함되었는지 확인
블랙리스트는 주로 Redis와 같이 접근 속도가 빠른 인-메모리 저장소에 저장하거나, DB에 저장
장점
- 세분화된 제어: 다른 토큰들에 영향 없이 특정 토큰만 무효화 할 수 있음
- 호환성: 다양한 백엔드 환경에서 사용 가능함
단점
- 확장성: 블랙리스트에 포함된 토큰 수가 증가하면 블랙리스트 조회 성능이 저하될 수 있음
- 서비스가 Stateful해짐: 블랙리스트를 계속 유지한다는 것은, 상태를 계속 유지한다는 것과 사실상 동일. 이는 JWT의 Stateless한 특성과 상충됨

짧은 토큰 수명

토큰의 수명(exp)을 매우 짧게 설정해, 공격자가 액세스 토큰을 탈취해도 많이 사용할 수 없음.
이는 공격자가 리프레시 토큰은 탈취하지 못한 경우 매우 유용
장점
- 노출 감소: 토큰이 탈취되어도 공격에 노출되는 시간이 최소화됨
- Stateless 유지: 별도의 서버 측 저장소가 필요하지 않음
단점
- 사용자 경험: 사용자가 더 자주 인증해야 함
- 즉각적인 해지 불가능: 탈취당해도 해당 토큰이 수명에 다다르길 기다려야 함

비밀 로테이션

JWT 서명에 사용되는 비밀(secret) 키를 주기적으로 교체하면, 이전 비밀 키로 서명된 모든 기존 토큰들을 무효화 할 수 있음
- 이는 보안 사고가 발생했거나, 인증 전략을 변경한 뒤 많은 수의 토큰을 동시에 해지해야할 때 특히 유용
장점
- 매우 안전: 정기적으로 로테이션되는 비밀은 보안 계층을 추가하는 셈
- 광범위한 영향: 기존의 모든 토큰들을 한 번에 무효화 해야하는 케이스에 매우 효과적
단점
- 복잡한 키 관리: 실수로 합법적인 토큰을 무효화하지 않도록 신중한 관리가 필요
- 토큰 재생성: 비밀 로테이션 이후 클라이언트는 새로운 JWT를 획득해야 해 클라이언트-백엔드 간 상호 작용 복잡하게 만들 수 있음

토큰 버전 관리

발행된 각 JWT에 버전 번호를 할당한 뒤, 사용자의 계정 정보와 함께 DB에 저장
만약 토큰을 무효화해야 할 경우, DB의 버전 번호를 증가시켜 이전 토큰들을 무효화
- 증가된 이후, 사용자가 인증을 시도할 경우 업데이트된 버전이 포함된 토큰을 제시해야 함
장점
- 선택적 무효화: 사용자의 계정 상태나 기타 기준에 따라 특정 대상만 무효화 할 수 있음
- 호환성: 다양한 신원 제공자 및 인증 시스템과 함께 사용될 수 있음
단점
- 복잡성 증가: 토큰 버전 역시 검증해야 하므로 추가적인 로직이 필요
- 데이터베이스 종속성: DB 검색을 통해 토큰 버전을 검증하므로, 검색하는데 지연 시간이 발생할 수 있음

사용자 로그아웃 및 강제 토큰 무효화

사용자가 로그아웃 할 때, 서버에서 마킹하거나 세션을 만료시켜 JWT 토큰을 무효화
- 로그아웃 이후 탈취된 토큰을 사용하는 것을 방지
장점
- 즉시 발동: 토큰이 즉시 무효화 됨
- 사용자 제어: 사용자는 로그아웃을 통해 본인의 세션 보안을 제어할 수 있음
단점
- Stateful함: 토큰 무효화를 위해 서버측 상태를 유지해야 함
- 구현 복잡성: 분산 환경과 같이 여러 엔드포인트가 있는 경우 구현하기 어려울 수 있음

토큰 무효화 목록(Token Revocation List, TRL)

토큰 블랙리스트와 유사하지만, 토큰 취소 여부를 확인하기 위한 쿼리 가 가능한 중앙 집중/분산형 서비스로 구현됨
- 이는 여러 서비스, 엔드포인트에서 취소 여부를 확인해야 하는 대규모 분산 시스템에 효과적
장점
- 확장성: 분산 환경에서 높은 부하를 처리하도록 설계됨
- 중앙 집중식 관리: 토큰 무효화를 중앙 집중화해 토큰 무효화 정책의 관리를 간소화
단점
- 지연 시간: 토큰 무효화 목록이 인-메모리 DB에 저장되지 않거나 최적화가 되어있지 않은 경우 지연시간 발생 가능
- 복잡성: TRL의 구현 및 유지를 위한 신중한 설계 필요

토큰에 유저 컨텍스트 포함하기 #

토큰에 유저 컨텍스트를 추가해 사용자인지 공격자인지 식별.
유저 컨텍스트는 다음과 같은 정보로 구성됨
- 인증 단계에서 무작위 문자열을 생성해, 굳어진 쿠키(hardend cookie)로 클라이언트에게 전송
  - 굳어진 쿠키는 HttpOnly + Secure + SameSite + Max-Age + cookie prefixes와 같은 플래그가 설정된 쿠키
  - 이때, 쿠키의 수명(Max-Age)은 JWT 만료값(exp)보다 작거나 같도록 설정해야 함
- 공격자가 이를 읽고 예상되는 쿠키를 설정하는 XSS 문제를 방지하기 위해, 무작위 문자열의 SHA256 해시를 원본 값 대신 토큰에 저장
서버는 토큰 검증 중 올바른 컨텍스트가 포함되지 않은 경우, 토큰을 거부해야 함.

참고

[웹, 네트워크] XSS 알아보기

Tue, 19 Mar 2024 19:51:00 +0900

서론

CS 스터디에서 3월 12일 발표한 XSS에 대해 정리한 문서를 블로그에 공유하고자 한다.

XSS란?

신뢰할 수 있는 웹 사이트에 악성코드를 삽입하는 공격을 말합니다.
공격자가 표적 웹사이트의 콘텐츠에 악성 스크립트를 삽입하고, 피해자의 브라우저에 전달되는 동적 콘텐츠에 이를 포함시키므로써 피해를 입게 됩니다.
이때, 피해자의 브라우저는 해당 스크립트가 ‘신뢰할 수 없는 스크립트’라는 점을 알 수 없어 해당 스크립트를 실행하게 됩니다.
악성 스크립트는 피해자의 브라우저가 보유한 해당 사이트에서 사용되는 모든 쿠키, 저장소에 저장된 민감 정보에 액세스할 수 있습니다.
뿐만 아니라 멀웨어를 퍼뜨리거나, 웹사이트의 콘텐츠를 변조하거나,피싱 사이트로 이동시키거나 하는 등의 공격도 가능합니다.
다른 웹 공격들과 달리, 애플리케이션 자체가 아닌 웹 애플리케이션 사용자를 표적으로 삼는다는 특징이 있습니다.

XSS 공격의 종류

`저장형 크로스사이트 스크립팅(Stored Cross-site Scripting)`

지속적(Persistent) XSS라고도 하는 공격 방식입니다.
사용자가 입력한 값이 저장(주로 게시판)된 후 이를 웹 페이지에서 출력할때 피해가 발생하는 공격입니다.
공격자의 악성스크립트가 서버에 저장되어 불특정 다수를 대상으로 공격에 이용될 수 있어 Reflected XSS보다 공격 대상의 범위가 훨씬 크다는 특징이 있습니다.

공격 방식

공격자가 스크립트가 포함된 콘텐츠(게시글, 댓글, 사용자 이름 등)를 작성한 뒤, 이를 피해자가 요청하게 되면 해당 스크립트가 피해자 측에서 동작하게 됩니다.

`반사 크로스사이트 스크립팅(Reflected cross-site scripting)`

비지속적(Non-Persistent) XSS라고도 하는 공격 방식입니다.
이름에 포함된 ‘반사’ 라는 단어처럼, 사용자가 요청한 스크립트가 사용자 측에서 반사되어 동작합니다. 즉, 공격자의 스크립트가 별도의 저장소에 저장되지 않고 사용자 측에서 즉시 동작합니다.
지속적 XSS와 달리, 공격자가 각 피해자들에게 페이로드(악성스크립트)를 전달해주어야 합니다. 따라서 악성 링크, 피싱 이메일, SNS 등을 이용해 해당 페이로드가 포함된 URL을 클릭하도록 유도해야 합니다.

공격 방식

공격자가 악성스크립트가 웹서버로 전송되는 요청(URL)의 일부가 되도록 합니다. 요청과 함께 포함되어있던 악성 스크립트가 사용자의 브라우저에서 동작하게 됩니다.

`DOM 기반 크로스사이트 스크립팅(DOM-based cross-site scripting)`

공격자의 스크립트가 HTML 내부가 아닌, DOM에 나타나는 공격 방식입니다.
반사/저장형 XSS에서는 응답 페이지에서 스크립트를 확인할 수 있는것과 다르게 HTML 소스 코드와 응답 페이지의 코드가 동일하기 때문에 페이로드를 찾을 수 없습니다.
따라서 런타임일때, 또는 페이지의 DOM을 조사해야만 스크립트를 찾을 수 있습니다.
DOM 기반 XSS는 주로 Client-side 공격으로, 악성 스크립트는 서버로 전송되지 않습니다. 따라서 서버 로그를 분석해도 공격을 확인할 수 없습니다.

공격 방식

공격자가 악성스크립트가 포함된 URL을 요청하면, 해당 스크립트를 실행해 DOM 영역을 변경합니다. 브라우저 자체에서 스크립트가 실행되어 DOM 영역을 변화시키므로 서로 패킷을 보내지 않고 공격이 수행됩니다.
주로 document, location와 같은 DOM 객체를 조작해 공격을 수행합니다.

CSRF랑 XSS의 차이점?

크로스-사이트 요청 위조(Cross-site Request Forgery)와 크로스-사이트 스크립팅(Cross-site Scripting) 모두 웹 애플리케이션에서 발견되는 보안 취약점입니다.
두 공격 방식의 가장 큰 차이는 인증된 세션(쿠키 등)을 활용하느냐 여부 입니다.
CSRF 공격은 사용자의 인증된 세션을 악용하는 공격 방식이고, XSS 공격은 사용자가 특정 사이트를 신뢰한다는 사실을 이용해 인증된 세션 없이도 공격할 수 있는 공격 방식입니다.

CSRF	XSS
사용자가 공격 사실을 모르는채 대상 웹사이트에 악성 요청을 보내도록 합니다.	웹 사이트에 클라이언트 측 스크립트를 삽입해 공격합니다.
공격을 수행하기 위해 Javascript가 필요하지 않습니다.	공격을 수행하기 위해 Javascript가 필요합니다.
악성 스크립트가 다른 사이트에 저장되어 있습니다.	웹 사이트가 악성 스크립트를 허용합니다.
취약한 URL에서 수행하는 작업만 수행할 수 있습니다.	공격자가 취약점을 이용해 원하는 모든 행동을 할 수 있습니다.

XSS는 프론트엔드에서만 방어할 수 있을까?

XSS 공격은 프론트엔드 뿐만 아니라, 백엔드단에서도 방어할 수 있습니다.
프로그래밍 언어와 웹 프레임워크 별로 방어 할 수 있는 방법들이 다양하지만, 해당 방법들의 주요 전략은 '사용자 입력 값을 전처리한다'입니다.
스크립트에서 자주 사용되는 <, >, (, ) 와 같은괄호를 HTML로 바꾼다거나, Lucy-XSS-Filter, OWASP ESAPI와 같은 라이브러리를 사용해 방어할 수 있습니다.
또한, Spring에서는 Spring Security에서 제공하는 X-XSS-Protection 헤더를 사용할 수도 있습니다.

`X-XSS-Protection`

브라우저에게 XSS 공격처럼 생긴 스크립트를 차단하도록 지시합니다.
해당 기능을 사용하면 브라우저는 XSS 공격을 감지했을때 이를 렌더링하지 않지만, 일부 웹 브라우저는 이에 필요한 XSS 감사기(Auditor)를 구현하지 않아 해당 헤더를 사용할 수 없습니다. 이를 보완하기 위해 콘텐츠 보안 정책(CSP) 기능을 사용할 수도 있습니다.

다만, 구글에서는 2019년 8월 XSS 감사기를 삭제했습니다.
- 지난 수 년 동안 XSS 감사기에 대한 수많은 우회 방법들이 제시되었고, 합법적인 사이트에 대한 액세스를 차단하는 경우도 존재했기 때문에 구글에서는 이를 삭제했습니다.
- 이후 DOM 기반 XSS 공격에 대한 방어책인 Trusted Types API 를 도입했습니다.

`콘텐츠 보안 정책(CSP)`

CSP는 XSS와 데이터 인젝션 공격을 완화하는데 도움을 주는 추가 보안 계층입니다. 이를 사용하려면 Content-Security-Policy 헤더를 반환하도록 애플리케이션을 구성해야 합니다.

@Configuration
public class SecurityConf {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.headers(headers ->
                headers.xssProtection(
                        xss -> xss.headerValue(XXssProtectionHeaderWriter.HeaderValue.ENABLED_MODE_BLOCK)
                ).contentSecurityPolicy(
                        cps -> cps.policyDirectives("script-src 'self'")
                ));
        return http.build();
    }
}

참고 문서

[웹, 네트워크] SOP 알아보기

Tue, 19 Mar 2024 19:50:47 +0900

서론

CS 스터디에서 3월 20일 발표예정인 SOP에 대해 정리한 문서를 블로그에 공유하고자 한다.

SOP 정책이란?.

동일 출처 정책(SOP, Same Origin Policy) 은 한 출처에서 불러온 문서 또는 스크립트가 다른 출처의 자원과 상호 작용하는 방식을 제한하는 보안 메커니즘입니다.
다른 출처의 자원과의 상호 작용을 제한하므로써, 잠재적으로 악의적인 문서들로 부터 격리시켜 가능한 공격 경로를 줄일 수 있습니다. 이러한 격리를 통해 악성 웹사이트가 사용자가 로그인한 타 서비스의 데이터를 읽고 공격자에게 전달하는 것을 막을 수 있습니다.

`출처(Origin)`?

웹에서 같은 출처인지 판단하는 기준은 URL의 프로토콜, 포트(지정된 경우), 호스트 이름(hostname)이 모두 동일한 지 입니다. 이를 튜플이라고 부르기도 합니다.

호스트 이름(hostname) : 네트워크에 연결된 컴퓨터 또는 기타 장치에 할당되는 이름으로, 로컬 호스트 이름(local hostname)과 도메인 이름(domain name)의 조합으로 구성됩니다.
- 예시) en.wikipedia.org
  - en(로컬 호스트 이름)과 wikipedia.org(도메인 이름)으로 구성되어 있습니다.

예시

http://store.company.com/dir/page.html 라는 URL을 기준으로 예시를 들어보겠습니다.

동일한 출처

아래 링크들은 경로만 다른 케이스 입니다.

http://store.company.com/dir2/other.html
http://store.company.com/dir/inner/another.html

다른 출처

프로토콜이 다른 경우

https://store.company.com/page.html

포트가 다른 경우

http://store.company.com:81/dir/page.html

호스트 이름이 다른 경우

http://news.company.com/dir/page.html

출처 변경 공격

이전에는 DOM 객체인 document의 document.domain을 조작해 도메인을 현재 도메인 또는 상위 도메인으로 변경할 수 있었으나, 보안 문제 때문에document.domain 설정자가 사장되어(deprecated) 해당 방식 공격은 불가능하게 되었습니다.

교차출처 접근의 종류

교차출처 쓰기

링크, 리다이렉션, form 제출 등의 작업으로, 일반적으로 허용되는 작업입니다. 일부 HTTP 요청은 preflight가 필요합니다.

교차출처 임베딩

일반적으로 허용됩니다.
<script>(javascript), <link>(css), <img>, <video>, <audio>, <object>, <embed>, <iframe>, @font-face(일부 브라우저 한정) 등이 있습니다.

교차출처 읽기

일반적으로 허용되지 않으나, 임베딩을 통해 읽기 접근이 유출되는 경우가 있습니다.

ex) 임베딩된 이미지의 크기, 임베딩된 스크립트의 동작

CORS 정책이란?

교차 출처 리소스 공유(CORS, Cross-Origin Resource Sharing)는 다른 출처의 자원을 접근할 수 있도록 허용하는 정책을 말합니다.
이는 서버에서 웹 브라우저가 해당 자원을 읽을 수 있는 출처를 설명할 수 있는 새로운 HTTP 헤더 (Access-Control-Allow-Origin)를 추가하는 방식으로 동작합니다.
클라이언트에서는 교차출처 자원을 호스팅하는 서버에 ‘서버가 실제 요청을 허용할 것인지‘를 확인하기 위해 브라우저가 preflight 요청을 전송하는 메커니즘을 사용합니다.

CORS를 사용하는 요청

fetch(), XMLHttpRequest 호출
웹 폰트(@font-face)
WebGL 텍스처
이미지/비디오 프레임
- <canvas>상에서 drawImage()를 이용해 그려진
이미지상의 CSS 도형

CORS 관련 헤더

`Access-Control-Allow-Origin`

응답 헤더 중 하나로, 서버의 자원 소유자가 특정 도메인에서의 요청만 허용해 자원에 대한 접근을 제어하는데 쓸 수 있는 헤더입니다.

// https://foo.example에서의 접근만 허용하는 경우
Access-Control-Allow-Origin: https://foo.example
// 모든 도메인으로부터 접근을 허용하는 경우 (자격증명이 필요 없는 요청인 경우)
Access-Control-Allow-Origin: *

자격 증명: 쿠키, TLS 클라이언트 인증서, 인증 헤더와 같은 인증 정보를 담은 것을 말하며, Access-Control-Allow-Credentials(응답 헤더)가 true인 경우 사용자는 교차 출처 요청에 자격 증명을 포함할 수 있습니다.

완화 방법

`Access-Control-Allow-Origin` 응답 헤더 설정

서버 측에서 요청을 허용할 출처를 명시적으로 설정해줍니다.
만약 자격증명이 필요한 경우, *는 사용할 수 없습니다.

Access-Control-Allow-Origin: <origin> | *

프록시 서버 사용하기

웹 애플리케이션에서 직접 자원에 접근하지 않고, 프록시 서버를 사용해 요청을 전달하는 방식입니다. 이는 SOP 정책이 브라우저-서버 간 통신에서만 구현된다는 점을 이용합니다.
웹 애플리케이션과 프록시 서버간에는 Access-Control-Allow-Origin: * 응답 헤더를 추가해 자유롭게 요청을 주고 받습니다.
그리고 서버-서버 간 통신에서는 SOP 정책을 만족할 필요가 없으므로 프록시 서버에서는 자유롭게 교차출처 자원에 접근할 수 있습니다.

Preflight란?

다른 출처의 자원에 대해 OPTIONS 메서드 요청을 먼저 전송해, 실제 요청을 전송해도 안전한지 확인하는 방식을 말합니다.
브라우저에서는 CORS를 사용하는 요청에 대해 OPTIONS 메서드를 자동으로 보내는데, 이때 원본 요청의 메서드, 헤더와 같은 값을 Access-Control-Request-... 과 같은 헤더에 담아서 해당 메서드, 헤더로 요청을 전송할 수 있는지 확인합니다.
그리고 서버는 이에 대한 응답에 Access-Control-Allow-... 와 같은 헤더를 담아 허용되는 메서드, 헤더 등에 대한 정보를 알려줍니다.

Preflight 관련 헤더

요청 헤더

`Origin`

요청을 발생시킨 출처(스키마, 호스트 이름, 포트)를 나타냅니다.
user agent가 페이지에 포함되거나, 페이지 내 스크립트가 접근하는 자원에 대해 요청해야 하는 경우 페이지의 출처가 요청에 포함될 수 있습니다.

일반적으로 user agent는 모든 교차출처 요청, 또는 동일 출처에 대해 GET, HEAD를 제외한 요청에 대해 Origin 헤더를 추가합니다.

// 특정 케이스의 경우 Origin은 null일 수 있습니다.
Origin: null
// 스키마(사용되는 프로토콜)와 호스트 이름(+ 포트)의 조합으로 Origin이 표시됩니다.
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>

`Access-Control-Request-Method`

원본 요청의 메서드가 어떤 것인지를 나타냅니다.

// ex) post 요청인 경우
Access-Control-Request-Method: POST

`Access-Control-Request-Headers`

원본 요청의 헤더로 어떤 것이 있는지를 나타냅니다.

// ex) 헤더에 X-PINGOTHER, Content-Type를 담은 경우
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

응답 헤더

`Access-Control-Allow-Origin`

`Access-Control-Allow-Methods`

요청한 자원에 대해 쿼리할 수 있는 유효한 메서드들을 알려줍니다. (쉼표로 구분) 모든 메서드를 허용하기 위해 *(와일드카드)를 쓸 수 있지만, 자격 증명이 없는 요청(HTTP 쿠키 또는 authentication이 없는)에 한해서만 사용할 수 있습니다.

// ex) POST, GET, OPTIONS 메서드만 허용되는 경우
Access-Control-Allow-Methods: POST, GET, OPTIONS

`Access-Control-Allow-Headers`

원본 요청의 헤더 중 허용되는 헤더를 알려줍니다. (쉼표로 구분) 모든 헤더를 허용하기 위해 *를 쓸 수 있지만, 자격 증명이 없는 요청(HTTP 쿠키 또는 authentication이 없는)에 한해서만 사용할 수 있습니다. 또한, *를 사용해도, Authorization 헤더의 경우 명시적으로 나열해야 합니다.

// ex) X-PINGOTHER, Content-Type 헤더가 허용되는 경우
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
// ex) 'X-Custom-Header' 라는 사용자 지정 헤더가 허용되는 경우
Access-Control-Allow-Headers: X-Custom-Header

`Access-Control-Max-Age`

preflight의 결과(즉 Access-Control-Allow-Methods, Access-Control-Allow-Headers에 포함된 정보)가 캐시될 수 있는 기간을 알려줍니다. 결과를 캐시할 수 있는 최대 시간(초)를 나타내며, 브라우저마다 최대치(파이어폭스:24시간, 크로미움(v76이전): 10분, 크로미움(v76이후): 2시간)가 다릅니다.

// ex) preflight의 결과가 캐시로 10분동안 저장됩니다.
Access-Control-Max-Age: 600