Websocket 클라이언트에서 전송할 때 마스킹이 정말로 필요합니까?

현재 Websocket RFC를 사용 하려면 웹 소켓 클라이언트 가 전송할 때 프레임 내의 모든 데이터를 마스크해야 하지만 서버는 필요하지 않습니다. 프로토콜이 이런 식으로 설계된 이유 는 클라이언트와 서버 사이의 악성 서비스 (프록시 등)에 의해 프레임 데이터가 변경되는 것을 방지하기 위함입니다. 그러나 마스킹 키는 여전히 이러한 서비스에 알려져 있습니다 (각 프레임 시작시 프레임 단위로 전송 됨).

프레임을 다음 지점으로 전달하기 전에 이러한 서비스가 여전히 키를 사용하여 내용을 마스크 해제, 변경 및 다시 마스크 할 수 있다고 가정하는 것이 잘못입니까? 내가 틀리지 않으면이 취약점을 어떻게 해결합니까?

security protocol websockets

— JSON
소스

답변:

RFC의 10.3 절 에서는 마스킹이 필요한 이유를 정확하게 설명합니다. 특정 해킹 기술에 대한 매우 구체적인 응답입니다. 이 문제를 해결하려는 문제 는 가장 날카로운 인터넷 전송 보안 담당자 중 일부가 재미와 이익 을 위해 말하기 라는 2010 논문에 설명되어 있습니다.

클라이언트-서버 마스킹은 프록시가 WebSockets 데이터를 무의식적으로 캐시 가능한 HTTP 요청으로 처리하지 못하도록 Websocket 프로토콜에서 사용합니다. 그것이 바보 같은 프록시로 넘어 가고 있는지 논쟁 할 수는 있지만 그 이유입니다.

— 로스 패터슨
소스

예, 그러나 웹 소켓 서비스 (클라이언트 측과 서버 측)로 가득 찬 손으로 작업 한 후에 프로토콜에 대해 잘 이해하고 있다고 생각합니다. 프록시가 마스크를 해제하고 수정하는 것이 어려울 것입니다. 즉석에서 프레임. a) 마스킹 키, b) 사람이 중간 데이터를 변경할 수 있도록 마스킹 키가 예측하지 않다 [예 해시로서 상기 데이터에 기초되지 및 키 자체는 C) (I 믿어) 프록시 CAN 유효한 클라이언트 세션이 생성 / 허용 / 몰래되면 유효한 클라이언트로 완전히 새롭고 원치 않는 프레임 [적절하게 마스킹되고 모두]을 전달할 수 있습니다.

— JSON

그 말로, 나는 또한이 결정이 내려 졌을 때 그들의 이사회에 많은 배경 지식과 경험이 없을 것임을 이해합니다.

— JSON

해당 섹션이나 참조하는 논문을 읽지 않은 것 같습니다. 마스킹은 프록시가 데이터를 읽지 못하게하는 것이 아니라 WebSockets 데이터 를 무의식적 으로 캐시 가능한 HTTP 요청 으로 처리 하지 못하도록합니다 . 그것이 바보 같은 프록시로 넘어 가고 있는지 논쟁 할 수는 있지만 그 이유입니다.

— 로스 패터슨

설명은 +1입니다. 더 나은 대답을 한 것 같습니다. 원래 답변을 편집 할 수 있다면 좋을 것입니다.

— JSON

wss://SSL / TLS를 통한 일명 WebSocket 에는 마스킹이 유용하지 않습니다 . 가능할 때마다 SSL / TLS를 사용하는 것이 권장되므로 마스킹이 한계 사용 사례를 포함한다고 합리적으로 결론을 내릴 수 있습니다.

— 로랑 칼레
소스

이것은 실제로 의견 이었지만, 아직 평판이 충분하지 않습니다 ....

— Adam Zuckerman