히포

ALPN

• ALPN은 Application Layer Protocol Negotiation의 약어
• ALPN(Application-Layer Protocol Interval)은 "Hello 메시지" 교환 내에 프로토콜 협상을 포함하는 TLS 확장
• ClientHello의 확장 기능으로, TLS handshake 이후에 application layer의 프로토콜과 버전을 결정하기 위한 기능
• ALPN → 프로토콜을 협상
  1. secure connection을 통해 처리
  2. 효율적인 접속
  3. 추가적인 round trips을 방지

• HTTP/2 프로토콜은 ALPN을 사용하여 웹사이트 로딩 시간을 줄이고 연결을 더 빠르게 암호화함
• 핸드셰이크 프로세스는 client에서 server까지 왕복 2회에 해당
• round trips이 많을수록 대기 시간은 길어지고 사용자는 서버로부터 정보를 받기 위해 더 오래 기다려야 함
• round trips의 수는 주로 client와 server(ex.. DNS, TCP, HTTP) 간의 통신을 시작하기 위한 핸드셰이크에서 발생
• round trips이 적은 상태에서 데이터를 전송하는 프로토콜을 개선할 수 있다면, 페이지 로딩 시간도 개선 가능

• ALPN은 HTTP/2에서는 HTTP의 버전을 합의하기 위해서 ALPN을 사용
• 먼저 client가 자신이 HTTP/1.1과 2를 지원한다는 사실을 ALPN으로 전송
• server가 ALPN과 HTTP/2를 지원한다면 ServerHello의 확장 필드에 h2를 적으면 handhshake 이후 HTTP/2로 통신이 시작
• ALPN을 지원하지 않으면, ServerHello에 ALPN 필드가 없으므로 HTTP/1.1로 통신
  
  
  

TLS handshake 동작 원리

• ALPN 확장을 사용할 경우의 이점을 완전히 이해하기 위해서는 먼저 TLS 핸드셰이크가 어떻게 작동하는 지 숙지 필요

• TLS handshake 단계 (TLS 포함)
  1. client와 server는 "Hello 메시지"를 교환하여 알고리즘에 합의하고 랜덤 값을 교환(exchange random value)하며 세션 재개(session resumption)를 확인
  2. 필요한 암호 파라미터(cryptographic parameters)의 교환을 통해 client와 server가 premaster secret를 허용
  3. master secret은 premaster secret에서 생성되고 임의의 값을 교환
  4. record layer에 security parameters를 제공
  5. client와 server는 peer가 동일한 security parameters를 계산했는지, 공격자가 조작하지 않고 handshake가 발생했는지 확인

• premaster secret
  • Client는 세션키를 생성하여 서버에게 전송
  • 암호화된 세션키를 premaster secret이라고 함

• master secret
  • 서버측에서 복호화할 때 사용
  • premaster secret을 통해 master secret가 생성
  • premaster secret을 사용하여 master secret를 복호화 → 데이터 추출 가능

ALPN의 동작 원리

1. ALPN client는 "TLS ClientHello 메시지"가 지원되는 application protocol 목록을 server로 전송 → "ClientHello 메시지" 안에 지원하는 목록을 가진 ProtocolNameList 필드를 추가
2. 목록을 수신한 server는 프로토콜을 선택하고 "ServerHello 메시지"로 프로토콜을 다시 전송 → 수신한 ProtocolNameList 필드를 살피고 "SeverHello 메시지"의 일부에 선택된 프로토콜을 나타내는 ProtocolName 필드를 반환
3. Server는 하나의 프로토콜 명을 응답하겠지만, 만약 Client가 요청한 목록에서 지원되는 것이 없다면 연결은 끊어지게 됨
4. 일단 TLS hadnshake가 완료되면 보안 연결이 수립되고 Client 와 Server는 어떤 응용프로그램 프로토콜을 사용할지 동의
5. 협상된 프로토콜을 통해 Client와 Sever는 바로 메시지를 교환 가능
6. aplication protocol negotiation은 TLS handshake 내에서 하나의 round trip에서 달성
7. 위 방법은 server가 각 application protocol에 다른 인증서를 연결할 수 있도록 함
8. support protocols 목록은 first message에서 server로 전송되어 필요한 왕복 여행의 양을 최소화

NPN vs ALPN (NPN과 ALPN의 비교)

1. NPN(client가 프로토콜 선택)

• Next Protocol Negotiation의 약어
• TLS Handshake 중에 효과적인 응용프로그램 프로토콜 협상을 위해서 구글에서 개발한 SPDY의 일부로 개발된 TLS 확장
• NPN은 ALPN의 전신이며 SPDY와 함께 널리 사용 (ALPN과 상당히 유사)
• NPN은 "ClientHello 메시지"에 지원되는 프로토콜 목록을 포함 X → ALPN과 차이
• NPN extension에서는 "ClientHello 메시지"에 프로토콜 목록이 포함되지만 일반적인 NPN은 client가 선택할 수 있는 프로토콜 목록을 다시 보내는 것은 server이다.

2. ALPN (server가 프로토콜 선택)

• NPN을 업그레이드 한 버전(client와 server의 프로토콜 목록 전송은 반대 과정)
• ClientHello 메시지는 server가 선택할 수 있도록 지원되는 프로토콜 목록을 포함
• ALPN은 "ClientHello 메시지"를 받은 이후 리소스 선택 프로세스(resource selection process)를 시작할 수 있어 역방향 프록시(reverse proxy)에도 유리
• ALPN이 다른 프로토콜 협상 표준과 더 유사
  
  
  

ALPN의 성장

• HTTP/2는 사용자 경험 향상(better user experience)과 로딩 시간 단축(faster load times)으로 인기가 높아짐
• ALPN 확장이 HTTP/2와 결합하여 제공됨으로 ALPN도 같이 성장
• 2016년 SPDY가 공식 폐지되면서 HTTP/2의 성장이 두드러짐
• 인상적인 속도 및 강화된 보안 기능으로 ALPN 발전
• 웹 사이트에서 HTTP/2 및 ALPN을 지원하는지 확인 : https://gf.dev/http2-test

ALPN 참고 자료 : https://www.ietf.org/proceedings/88/slides/slides-88-httpbis-1.pdf

• ALPN은 Application Layer Protocol Negotiation의 약어
• ALPN(Application-Layer Protocol Interval)은 "Hello 메시지" 교환 내에 프로토콜 협상을 포함하는 TLS 확장
• ClientHello의 확장 기능으로, TLS handshake 이후에 application layer의 프로토콜과 버전을 결정하기 위한 기능
  

  

• ALPN → 프로토콜을 협상

  1. secure connection을 통해 처리
  2. 효율적인 접속
  3. 추가적인 round trips을 방지
     
     
     

• HTTP/2 프로토콜은 ALPN을 사용하여 웹사이트 로딩 시간을 줄이고 연결을 더 빠르게 암호화함

• 핸드셰이크 프로세스는 client에서 server까지 왕복 2회에 해당

• round trips이 많을수록 대기 시간은 길어지고 사용자는 서버로부터 정보를 받기 위해 더 오래 기다려야 함

• round trips의 수는 주로 client와 server(ex.. DNS, TCP, HTTP) 간의 통신을 시작하기 위한 핸드셰이크에서 발생

• round trips이 적은 상태에서 데이터를 전송하는 프로토콜을 개선할 수 있다면, 페이지 로딩 시간도 개선 가능

• ALPN은 HTTP/2에서는 HTTP의 버전을 합의하기 위해서 ALPN을 사용
  1. 먼저 client가 자신이 HTTP/1.1과 2를 지원한다는 사실을 ALPN으로 전송
  2. server가 ALPN과 HTTP/2를 지원한다면 ServerHello의 확장 필드에 h2를 적으면 handhshake 이후 HTTP/2로 통신이 시작
  3. ALPN을 지원하지 않으면, ServerHello에 ALPN 필드가 없으므로 HTTP/1.1로 통신
     
     
     

TLS handshake 동작 원리

• ALPN 확장을 사용할 경우의 이점을 완전히 이해하기 위해서는 먼저 TLS 핸드셰이크가 어떻게 작동하는 지 숙지할 필요가 있음

1. TLS handshake 단계 (TLS 포함)

1. client와 server는 "Hello 메시지"를 교환하여 알고리즘에 합의하고 랜덤 값을 교환(exchange random value)하며 세션 재개(session resumption)를 확인
2. 필요한 암호 파라미터(cryptographic parameters)의 교환을 통해 client와 server가 premaster secret를 허용
3. master secret은 premaster secret에서 생성되고 임의의 값을 교환
4. record layer에 security parameters를 제공
5. client와 server는 peer가 동일한 security parameters를 계산했는지, 공격자가 조작하지 않고 handshake가 발생했는지 확인

2. premaster secret

• Client는 세션키를 생성하여 서버에게 전송
• 암호화된 세션키를 premaster secret이라고 함

3. master secret

• 서버측에서 복호화할 때 사용
• premaster secret을 통해 master secret가 생성
• premaster secret을 사용하여 master secret를 복호화 → 데이터 추출 가능
  
  
  

ALPN의 동작 원리

1. ALPN client는 "TLS ClientHello 메시지"가 지원되는 application protocol 목록을 server로 전송 → "ClientHello 메시지" 안에 지원하는 목록을 가진 ProtocolNameList 필드를 추가
2. 목록을 수신한 server는 프로토콜을 선택하고 "ServerHello 메시지"로 프로토콜을 다시 전송 → 수신한 ProtocolNameList 필드를 살피고 "SeverHello 메시지"의 일부에 선택된 프로토콜을 나타내는 ProtocolName 필드를 반환
3. Server는 하나의 프로토콜 명을 응답하겠지만, 만약 Client가 요청한 목록에서 지원되는 것이 없다면 연결은 끊어지게 됨
4. 일단 TLS hadnshake가 완료되면 보안 연결이 수립되고 Client 와 Server는 어떤 응용프로그램 프로토콜을 사용할지 동의
5. 협상된 프로토콜을 통해 Client와 Sever는 바로 메시지를 교환 가능
6. aplication protocol negotiation은 TLS handshake 내에서 하나의 round trip에서 달성
7. 위 방법은 server가 각 application protocol에 다른 인증서를 연결할 수 있도록 함
8. support protocols 목록은 first message에서 server로 전송되어 필요한 왕복 여행의 양을 최소화
   
   
   

NPN vs ALPN (NPN과 ALPN의 비교)

1. NPN(client가 프로토콜 선택)

• Next Protocol Negotiation의 약어
• TLS Handshake 중에 효과적인 응용프로그램 프로토콜 협상을 위해서 구글에서 개발한 SPDY의 일부로 개발된 TLS 확장
• NPN은 ALPN의 전신이며 SPDY와 함께 널리 사용 (ALPN과 상당히 유사)
• NPN은 "ClientHello 메시지"에 지원되는 프로토콜 목록을 포함 X → ALPN과 차이
• NPN extension에서는 "ClientHello 메시지"에 프로토콜 목록이 포함되지만 일반적인 NPN은 client가 선택할 수 있는 프로토콜 목록을 다시 보내는 것은 server이다.

2. ALPN (server가 프로토콜 선택)

• NPN을 업그레이드 한 버전(client와 server의 프로토콜 목록 전송은 반대 과정)
• ClientHello 메시지는 server가 선택할 수 있도록 지원되는 프로토콜 목록을 포함
• ALPN은 "ClientHello 메시지"를 받은 이후 리소스 선택 프로세스(resource selection process)를 시작할 수 있어 역방향 프록시(reverse proxy)에도 유리
• ALPN이 다른 프로토콜 협상 표준과 더 유사
  
  
  

ALPN의 성장

• HTTP/2는 사용자 경험 향상(better user experience)과 로딩 시간 단축(faster load times)으로 인기가 높아짐 → ALPN 확장이 HTTP/2와 결합하여 제공됨으로 ALPN도 같이 성장
• 2016년 SPDY가 공식 폐지되면서 HTTP/2의 성장이 두드러짐
• 인상적인 속도 및 강화된 보안 기능으로 ALPN 발전
• 웹 사이트에서 HTTP/2 및 ALPN을 지원하는지 확인 : https://gf.dev/http2-test
  
  
  

참고 자료 : https://www.ietf.org/proceedings/88/slides/slides-88-httpbis-1.pdf

• 특수문자 %20는 공백(스페이스), 즉 "빈 칸"을 의미

• 인터넷 주소에서는 원칙적으로 빈 칸이 들어갈 수 없음

• 빈 칸(공백)은 하나의 글자 → 공백문자의 아스키 코드(ASCII Code)는 10진수로는 32, 16진수로는 20임

• ASCII Code의 20를 활용하여 빈 칸을 인터넷 주소에서 %20으로 사용

  
  

• 아래처럼 빈칸이 있는 경우 호출 불가

  http://www.baidu.com/Hello Test.html

  
  

• 빈칸이 있는 주소에서 빈 칸을 %20 으로 변환하는 경우 호출 가능

  http://www.baidu.com/Hello%20Test.html

• HTTP 헤더 중에는 Vary 헤더가 있음

• Vary 헤더는 동일한 URL에 대해 요청을 하더라도 요청한 사용자의 특징(User Agent, Accept Encoding, Origin 등등)에 따라 서로 다른 응답을 해 주기 위해서 존재함

• 웹 캐시에서는 Vary 헤더를 확인하고 해당 헤더에서 명시하는 조건에 따라 동일 URL이라 하더라도 다른 종류의 컨텐츠를 캐싱하고, 제공함

• Vary 헤더는 200 OK 응답과 동일하게 304 Not Modified 응답에서도 설정되어야함

• Vary 헤더를 사용하는 경우, 서버는 캐쉬한 응답을 적절한 Accept-Encoding 요청 헤더를 보낸 클라이언트에게만 보내도록 Vary: Accept-Encoding으로 설정

  
  

• 하나의 웹컨텐츠를 데스크톱과 모바일에서 서로 다르게 보여줘야 할 경우가 있음 → URI 정보로는 동일한 컨텐츠

  1. 웹서버에서는 프로그램으로 잘 표현되나, 캐시서버가 컨텐츠를 캐싱하고 있는 경우 문제가 발생 가능
  2. 모바일에서 컨텐츠를 요청하였을 때, 캐시서버가 데스크톱 컨텐츠를 직접 전달하여 문제가 발생할 수 있음
  3. 반대로 데스크톱 컨텐츠를 요청하였을 때, 캐시서버가 모바일 컨텐츠를 직접 전달하여 문제가 발생할 수도 있음
  4. Vary 헤더의 값으로는 HTTP 요청 헤더명이 사용
  5. 예시로 User-Agent를 값으로 사용

     Vary: User-Agent

     
     

• 캐싱하고 있는 컨텐츠의 최초 User-Agent 정보가 일치하지 않으면 캐싱된 컨텐츠를 전달 X

• 최초 모바일로 트와이스 이미지를 요청하여 전달받게 되면 캐싱된 트와이스 이미지는 모바일 User-Agent 값인 경우에만 직접 전달 가능 ->데스크톱에서는 캐싱된 트와이스 이미지를 사용 불가
  
  
  

Vary 헤더를 사용한 캐시와 웹 서버의 동작

1. 모바일 사용자가 twice.jpg 이미지를 요청 (최초의 요청)
2. 최초 요청이기 때문에 캐시 서버는 웹서버에게 클라이언트의 요청을 그대로 전달
3. 웹 서버에게 클라이언트의 요청 이미지를 전달 받음(응답에 Vary: User-Agent 헤더 포함)
4. 전달받은 이미지는 캐시 서버의 저장공간에 저장한 후 모바일 사용자에게 전달
5. 동일한 이미지를 모바일 사용자가 아닌 데스크톱 사용자가 요청
6. 분명 동일한 URI 경로에 요청임에도 불구하고 캐싱된 이미지를 전달 X(이전 캐싱된 컨텐츠와 요청한 컨텐츠의 User-Agent가 다름) → 웹 서버에게 클라이언트의 요청을 그대로 전달
7. 웹서버가 캐시 서버에게 동일하지만 Vary 헤더가 다른 컨텐츠를 전달
8. 그렇기에 프록시 서버는 동일한 URI 요청임에도 불구하고 캐싱할 당시의 User-Agent 정보를 비교하고 내용이 다르기에 캐싱된 컨텐츠를 직접 전달 X → 응답 헤더의 Vary : User-Agent가 다른 경우 caching된 컨텐츠 전달 X
   

   

HTTP의 Vary 헤더의 문법

Vary: *
Vary: <header-name>, <header-name>, ...

HTTP Vary 헤더의 지시자

1. * (asterisk)

• 각 요청에 대해서 캐시할 수 없는 요청으로 간주
• 더 좋은 방법으로 Cache-Control: no-store를 사용 → 객체를 저장하면 안된다는 의미로 좀 더 명확하게 표시

2. <header-name>

• 헤더 이름은 쉼표로 구분되며 캐시된 응답을 사용할 수 있는지 여부를 결정할 때 사용
  

• HTTP 프로토콜에서 server 헤더는 웹 서버의 종류를 나타냄 →서버의 소프트웨어 정보
• 너무 길고 상세한 서버의 정보는 불특정한 상대에게 공격을 받을 수 있기 때문에 주의해야함
• 공격자들이 서버의 정보를 보고 쉽게 보안상의 문제점을 찾아 공격 가능
  

문법

Server: <product>

server 헤더의 지시자 <product>

• 요청을 처리하는 소프트웨어 혹은 하위 제품의 이름
• HTTP 프로토콜의 server 헤더의 사용 예제

  Server: Apache/2.4.1 (Unix)

  
  

• 클라이언트(웹브라우저)는 서버가 제공하는 컨텐츠에서 일부분을 다시 요청하거나 갱신할 필요가 있는 경우 발생
• HTTP Range 요청 헤더는 서버에게 데이터의 일부분만 요청하는 헤더

• HTTP 프로토콜 Range 헤더를 사용하는 경우
  1. 스트리밍같은 동영상 데이터일 경우 총 5분짜리 영상인데, 처음부터 2분까지만 먼저 다운 → 다시 다운로드를 받으려 할때, 굳이 0 ~ 2분까지 모든 데이터를 다시 받을 필요 X
  2. 웹서버에서 특정 파일을 다운로드 하고 있는 중 여러가지 이유로 다운로드가 완료되지 못하고 중간에 끊어지는 경우 발생 → 처음부터 다시 받기 보다는 중간에 다운로드가 끊긴 시점부터 다시 받으면 효율적

• HTTP 프로토콜에서 Range 헤더를 사용할 때 동작 흐름도
  1. 클라이언트는 웹서버에게 200~400 bytes에 해당하는 데이터를 달라고 요청
  2. 웹서버는 "206 Partial Content" 라는 상태코드 메시지와 함께 요청한 200~400 바이트에 해당하는 데이터를 전달함.
  3. 클라이언트는 Range 헤더를 통해 여러 부분을 한번에 요청 가능하며, 서버는 클라이언트가 요청한 범위에 대한 데이터를 전달 가능
  4. 범위가 유효하지 않다면, 서버는 "416 Range Not Satisfiable" 에러를 보냄
  5. 서버는 Range 헤더를 무시하고 200 상태 코드와 함께 전체 문서를 전송
     

     

     
     
     
     

Range 헤더 문법

Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>

Range 헤더 사용 예제

Range: bytes=200-1000, 2000-6576, 19000-

지시자

1. <unit>

• 범위를 결정하는 단위.
• 보통 bytes

2. <range-start>

• 범위 요청의 시작 지점을 알리는 단위를 뜻하는 정수.

3. <range-end>

• 요청한 범위의 끝을 알리는 단위를 의미하는 정수.
• range-end 값은 옵션으로 사용할 수 있으며, 생략한다면 문서의 끝부분을 요청의 끝으로 사용
  
  
  

• HTTP/1.0 Pragma 헤더는 요청-응답 체인에 다양한 영향을 줄 수 있는 구현 관련 헤더
• HTTP/1.0 헤더 옵션 중 하나
• HTTP/1.1 Cache-Control 헤더가 생기기 전, HTTP/1.0 Pragma 헤더는 Cache-Control 헤더의 역할을 대신하는 헤더로 사용
• 캐시가 캐시 복사본을 릴리즈 하기 전에 원격 서버로 요청을 날려 유효성 검사를 강제하도록 함
• Cache-Control: no-cache와 동일 효과 → HTTP/1.0 Pragma 헤더는 캐시서버가 응답한 컨텐츠를 저장하지 말 것을 요구하는 헤더
  
  
  

HTTP1.0에서 Pragma 헤더 사용법

• Cache-Control: no-cache 와 동일한 효과
• 서버에서 사용되는 경우는 중간의 캐시서버가 응답한 컨텐츠를 저장하지 말 것을 요구하는 헤더
• 요청이건 응답이건 포함되어 있는 경우에는 캐시서버의 캐싱 동작 자체를 거부

  Pragma: no-cache

  
  
  

Pragma 헤더 주의 사항

• Pragma는 HTTP 응답에서 명시되지 않았던 헤더 → HTTP/1.1 Cache-Control 헤더의 신뢰할만한 대체재로 사용될 수 없음
• Pragma 헤더는 HTTP/1.0를 사용하는 클라이언트만을 위한 비공식적인 헤더
• 캐시서버의 동작을 거부하려면, Expires 헤더와, Cache-Control을 이용하는게 HTTP 1.1에서는 더욱 바람직한 방법임

• Last-Modified 헤더는 브라우저가 서버로 요청한 파일의 최종 수정 시간을 알려줌
• Last-Modified 헤더는 응답을 HTTP 헤더에 서버가 알고 있는 가장 마지막 수정된 날짜와 시각을 담고 있음
• 저장된 리소스가 이전과 같은지 유효성 검사자로 사용
• ETag 헤더보다는 덜 정확하지만, Last-Modified 헤더는 ETag 헤더에 대한 차선책으로 사용
• Last-Modified 헤더를 쓸 경우 브라우저가 다음에 다시 접속할 때 서버에게 파일이 수정되었는지 여부를 물어봄 → 서버가 수정 여부를 내려주는 헤더인 조건 요청은 If-Modified-Since 또는 If-Unmodified-Since (en-US) 헤더를 사용
• 캐싱을 해 성능을 향상시킬 수 있는데 이미지/CSS/JS와 같은 정적파일들은 아파치에서 자동적으로 Last-Modified, If-Modified-Since 헤더를 붙여줌
• php파일과 같은 동적 파일들에는 로직상에서 헤더를 붙여주면 됨
• 응답 날짜 헤더(Date Header)는 언제 응답이 나타났는지 나타내는 반면, Last-Modified 헤더는 지난 할당되어진 자원이 바뀔 때를 나타냄
• 즉, Last-Modified value는 Date value보다 최근일 수 없음
  
  
  

Last-Modified 헤더의 사용시점

• Last-Modified 헤더는 시간 값을 기준으로 파일 수정 여부를 판별
• 짧은 시간 내에 변경되는 리소스 등에는 Last-Modified 헤더를 사용하는 것이 적합
  
  
  

Last-Modified 헤더 참고 사진

지시자

1. <etag>

• 개체 태그는 요청한 리소스가 유일한 것을 표현
• ASCII 문자열로 쌍따옴표("675af34563dc-tr34"처럼)로 묶여있음
• 접두사로 W/가 있어 약한 비교 알고리즘을 사용되어야 하는 것을 표시
• If-Range 헤더 사용 예제

  If-Range: Wed, 21 Oct 2015 07:28:00 GMT  

  
  

2. <day-name>

• "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중 하나가 표시
• 대소문자 구분

3. <day>

• 날짜
• 두 글자로 표시
• 예시 : "04" 또는 "23"

4. <month>

• "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나가 표시
• 대소문자 구분

5. <year>

• 연도
• 네 글자로 표시
• 예시 : "1990" 또는 "2016"

6. <hour>

• 시간
• 두 글자로 표시
• 예시 : "09" 또는 "23"

7. <minute>

• 분
• 두 글자로 표시
• 예시 : "04" 또는 "59"

8. <second>

• 초
• 두 글자로 표시
• 예시 : "04" 또는 "59"

9. GMT

• 그리니치 표준시
  HTTP 날짜는 현지 시각이 아닌, 언제나 GMT로 표현