MASQUE Multiplexed Application Substrate over QUIC Encryption

Михаил

Почетный гость
Всем доброго времени суток, поясните что это за технология от google русским языком, чёрным-по-белому и с чем ее едят.Как она функционирует, где применяется.
MASQUE Multiplexed Application Substrate over QUIC Encryption.
прикрепляю ссылку на исходник:https://tools.ietf.org/html/draft-schinazi-masque-01
 

Goblin

Случайный прохожий
This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a mechanism that allows co-locating and obfuscating networking applications behind an HTTPS web server. The currently prevalent use-case is to allow running a proxy or VPN server that is indistinguishable from an HTTPS server to any unauthenticated observer. We do not expect major providers and CDNs to deploy this behind their main TLS certificate, as they are not willing to take the risk of getting blocked, as shown when domain fronting was blocked. An expected use would be for individuals to enable this behind their personal websites via easy to configure open-source software.
 

awocose

Случайный прохожий
Masque - это механизм, который позволяет размещать и запутывать сетевые приложения за веб-сервером https. в настоящее время преобладающим вариантом использования является разрешение запустить прокси-сервер или vpn-сервер, который неотличим от https-сервера любому неаутентифицированному наблюдателю.
 

Doctor

Случайный прохожий
всем доброго времени суток, поясните что это за технология от google русским языком, чёрным-по-белому и с чем ее едят.как она функционирует, где применяется.
Masque multiplexed application substrate over quic encryption.
прикрепляю ссылку на исходник:https://tools.ietf.org/html/draft-schinazi-masque-01
это какие то выдержки из описания работы quic протокола
quic.png - quic masque
 

Михаил

Почетный гость
А вот конкретно по сравнению с QUIC какие различия?
"The server runs an HTTPS server on port 443, and has a valid TLS certificate for its domain. The client has a public/private key pair, and the server maintains a list of authorized MASQUE clients, and their public key. (Alternatively, clients can also be authenticated using a shared secret.) The client starts by establishing a regular HTTPS connection to the server (HTTP/3 over QUIC or HTTP/2 over TLS 1.3 [RFC8446] over TCP), and validates the server's TLS certificate as it normally would for HTTPS. If validation fails, the connection is aborted. At this point the client can send regular unauthenticated HTTP requests to the server. When it wishes to start MASQUE, the client uses HTTP Transport Authentication (draft-schinazi-httpbis-transport-auth) to prove its possession of its associated key. The client sends the Transport- Authentication header alongside an HTTP CONNECT request for "/.well- known/masque/initial" with the :protocol pseudo-header field set to "masque". When the server receives this CONNECT request, it authenticates the client and if that fails responds with code "405 Method Not Allowed", making sure its response is the same as what it would return for any unexpected CONNECT request. If authentication succeeds, the server responds with code "101 Switching Protocols", and from then on this HTTP stream is now dedicated to the MASQUE protocol. That protocol provides a reliable bidirectional message exchange mechanism, which is used by the client and server to negotiate what protocol options are supported and enabled by policy, and client VPN configuration such as IP addresses. When using QUIC, this protocol also allows endpoints to negotiate the use of QUIC extensions, such as support for the DATAGRAM extension [I-D.pauly-quic-datagram]. Clients MUST NOT attempt to "resume" MASQUE state similarly to how TLS sessions can be resumed. Every new QUIC or TLS connection requires fully authenticating the client and server. QUIC 0-RTT and Schinazi Expires"
 

Goblin

Случайный прохожий
работает поверх quic
переведу для широких масс
Сервер запускает сервер HTTPS на порту 443 и имеет действительный сертификат TLS для своего домена. У клиента есть пара открытого и закрытого ключей, а сервер поддерживает список авторизованных клиентов MASQUE и их открытый ключ. (В качестве альтернативы клиенты также могут проходить проверку подлинности с использованием общего секрета.) Клиент запускается с установления обычного HTTPS-соединения с сервером (HTTP / 3 через QUIC или HTTP / 2 через TLS 1.3 [RFC8446] через TCP) и проверяет сертификат TLS сервера как обычно это происходит для HTTPS. Если проверка не пройдена, соединение прерывается. В этот момент клиент может отправлять на сервер регулярные неаутентифицированные HTTP-запросы. Когда он хочет запустить MASQUE, клиент использует HTTP-аутентификацию транспорта (draft-schinazi-httpbis- transport-auth) для подтверждения наличия у него связанного ключа Клиент отправляет заголовок Transport-Authentication вместе с запросом HTTP CONNECT для "/.well-known / masque / initial" с полем псевдо-заголовка: protocol, установленным в "masque" ". Когда сервер получает этот запрос CONNECT, он аутентифицирует клиента и, в случае неудачи, отвечает кодом «405 Method Not Allowed», убедившись, что его ответ совпадает с тем, что он возвращает для любого неожиданного запроса CONNECT. Если аутентификация прошла успешно, сервер отвечает кодом «101 Switching Protocols», и с этого момента этот поток HTTP теперь назначается протоколу MASQUE. Этот протокол обеспечивает надежный механизм двунаправленного обмена сообщениями, который используется клиентом и сервером для согласования того, какие параметры протокола поддерживаются и активируются политикой и конфигурацией VPN клиента, такой как IP-адреса. При использовании QUIC этот протокол также позволяет конечным точкам согласовывать использование расширений QUIC, таких как поддержка расширения DATAGRAM [I-D.pauly-quic-datagram]. Клиенты НЕ ДОЛЖНЫ пытаться «возобновить» состояние MASQUE аналогично тому, как можно возобновить сеансы TLS. Каждое новое соединение QUIC или TLS требует полной аутентификации клиента и сервера. QUIC 0-RTT и Schinazi Expires
 
Верх Низ