Squid를 통한 WSS는 단순한 WebSocket 업그레이드와 같지 않습니다
CONNECT 안의 암호화된 WebSocket과 포워드 프록시의 평문 HTTP Upgrade 처리를 구분합니다.
Squid는 HTTP Upgrade 요청을 보는가, 아니면 암호화된 트래픽을 실은 터널만 보는가? 이것이 HTTP Upgrade 제어가 장애를 다루는지를 결정합니다.
| 일반적인 명시적 프록시 경로 | Squid가 마주치는 것 |
|---|---|
wss:// | 보통 CONNECT, 그 뒤에 WebSocket 핸드셰이크를 나르는 목적지 TLS |
ws:// | 프록시가 처리할 수 있는 평문 HTTP Upgrade 요청 |
Squid의 업그레이드 제어는 Squid가 처리하는 요청에 관한 것입니다. 일반적인 불투명 WSS 터널 안의 암호화된 HTTP 헤더를 드러내지는 않습니다. TLS 가로채기나 다른 특별한 프록시 처리는 가시성을 바꾸고 자체적인 호환성 요구를 낳을 수 있습니다.
WSS의 경우 어디서 순서가 멈추는지 찾으십시오. 프록시 연결, 수락된 CONNECT, 검증된 TLS, 그다음 애플리케이션 핸드셰이크입니다. TLS 이전의 거부는 거부된 평문 Upgrade 요청과 다른 장애입니다.
업그레이드 정책 변경이 필요하면 설치된 Squid 릴리스의 지시문을 사용하고 필요한 동작만 구체적으로 허용하십시오. 모든 업그레이드 프로토콜을 허용하면 정책이 해당 애플리케이션 너머로 넓어집니다.
HTTPS 페이지 요청이 성공해도 경로의 일부만 확인된 것입니다. 오래 유지되는 WebSocket 트래픽은 같은 호스트 이름에서도 애플리케이션 요구 사항, 연결 수명 또는 중간 장치의 제한 때문에 실패할 수 있습니다.