Apigee Edge 4.54.00의 Nginx 1.30 변경사항

Nginx 변경사항 개요

Private Cloud용 Apigee Edge 4.54.00에는 Edge 라우터에서 Nginx 버전 1.30으로의 필수 업그레이드가 포함되어 있습니다.

Nginx 1.26 출시와 함께 보안을 강화하고 HTTP 표준을 준수하기 위해 몇 가지 중요한 변경사항이 도입되었습니다. 주요 업데이트는 다음과 같습니다.

헤더 이름 및 값의 공백 처리

보안을 개선하기 위해 특히 헤더의 공백 처리와 관련하여 RFC 7230 준수가 강화되었습니다. 이러한 변경사항에 관한 자세한 내용은 부록을 참고하세요.

Content-Length 및 Transfer-Encoding 헤더 처리

요청 스머글링 공격에 사용되는 일반적인 기법 중 하나는 Content-Length 및 Transfer-Encoding 헤더가 모두 포함된 HTTP 요청을 전송하는 것입니다. Apigee Edge는 이미 이러한 공격에 대해 강화되었지만 이제 Nginx는 두 헤더가 모두 포함된 요청을 명시적으로 차단합니다. 이러한 요청이 전송되면 Nginx는 400 잘못된 요청 오류로 응답합니다.

지원되는 암호화

북쪽 요청에 지원되는 암호화 목록은 이 출시에서 변경될 수 있습니다. 라우터 호스트에서 OpenSSL에서 지원하는 암호화를 확인하여 사용 가능한 암호화의 업데이트된 목록을 가져올 수 있습니다.

지원되는 키 크기

이전에는 2,048비트보다 작은 RSA, DSA, DH 키와 224비트보다 작은 ECC 키가 기본적으로 허용되었습니다. 하지만 이 업데이트에서는 북쪽 요청의 단방향 및 양방향 TLS 연결 모두에 이러한 키가 더 이상 허용되지 않습니다.

부록

헤더의 공백

주요 변경사항은 세 가지입니다.

  1. 이전에 허용되었던 특정 헤더 이름이 이제 Nginx 1.26에서 허용되지 않습니다. 이러한 헤더가 포함된 요청은 400 잘못된 요청 오류를 발생시킵니다.
  2. 이전에 허용되었던 특정 헤더 값이 이제 Nginx 1.26에서 허용되지 않습니다. 이러한 헤더가 포함된 요청도 400 잘못된 요청 오류를 발생시킵니다.
  3. 이전에 Nginx에서 허용되었지만 메시지 프로세서에서 다운스트림 오류를 발생시킨 일부 헤더가 이제 Nginx에서 직접 거부됩니다. 이러한 헤더는 여전히 API 오류를 발생시키지만 HTTP 오류 메시지는 변경됩니다.

아래 섹션에서는 허용되지 않는 다양한 헤더 이름과 헤더 값의 예를 제공합니다. 이러한 예는 완전한 목록이 아닐 수 있습니다. 헤더에 RFC 7230의 가이드라인을 준수하는 것이 좋습니다.

헤더 이름 변경

이 섹션에서는 Nginx 1.20.1에서 허용되었지만 이제 Nginx 1.26에서 허용되지 않는 다양한 헤더 이름을 나열합니다.

시나리오 헤더 이름 예
헤더 이름의 시작, 끝 또는 중간에 있는 제어 문자 { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
헤더 이름의 선행 및 후행 공백 {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
헤더 이름의 선행 및 후행 HTAB {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
헤더 이름의 선행 및 후행 HTAB, WS 조합 {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
헤더 이름 사이에 있는 NewLine (\n) 바로 뒤에 WS 또는 일련의 WS가 오는 경우 {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
헤더 이름 사이에 있는 NewLine (\n) 바로 뒤에 HTAB 또는 일련의 HTAB가 오는 경우 {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
헤더 이름 사이에 있는 캐리지 리턴 (\r) NewLine (\n) 바로 뒤에 HTAB 또는 일련의 HTAB가 오는 경우 {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
헤더 이름 사이에 있는 캐리지 리턴 (\r) NewLine (\n) 바로 뒤에 WS 또는 일련의 WS가 오는 경우 {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

헤더 값 변경

이 섹션에서는 Nginx 1.20.1에서 허용되었지만 Nginx 1.26에서 허용되지 않는 다양한 헤더 값을 보여줍니다.

시나리오 예
HEADERVALUE 사이에 \r\n 또는 \r\n과 WS 또는 HTAB의 조합이 허용됨 {"Header47", "Value47\r\n MultiLine"},
{"Header48", "Value48\r\n MultiLine"},
{"Header49b", "Value49b\r\n \r\nMultiLine"},
{"Header50", "Value50 \r\n MultiLine"},
{"Header51", "Value51\r\n\tMultiLine"},
{"Header52", "Value52\r\n\t\tMultiLine"},
{"Header53", "Value53\t\r\n\tMultiLine"}
HEADERVALUE 사이에 \n 또는 \n과 WS 또는 HTAB의 조합이 허용됨 {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Value\n\t65"},
{"Header66", "Value\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Value\n 68"}

HTTP 실패 응답 변경

이 섹션에서는 이전 Nginx에서 허용되었지만 업스트림 메시지 프로세서에서 거부되어 400 상태 코드가 발생하는 헤더를 다룹니다. 하지만 Nginx 1.26에서는 이러한 헤더로 인해 Nginx에서 직접 오류가 발생하여 요청이 메시지 프로세서로 전달되지 않습니다.

이러한 헤더를 전송하는 클라이언트의 경우 HTTP 상태 코드는 400으로 유지됩니다. 하지만 이제 오류가 메시지 프로세서가 아닌 Nginx에서 생성되므로 HTTP 응답 본문이 변경될 수 있습니다.

시나리오 예
HEADERNAME 사이에 있는 HTAB 또는 WS

메시지 프로세서에서 이러한 요청을 거부합니다. Nginx 1.26에서는 이러한 요청이 Nginx 자체에서 거부됩니다. API 소비자는 본문에 Nginx 오류 메시지가 포함된 400 오류 응답을 받게 됩니다.

 {"Header 5", "Value5"},
{"Header\t14", "Value14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}