WABetaInfo: WhatsApp test extra instellingen Proxy-functie

WhatsApp test in bètaversie 2.23.13.10 extra instellingen voor de bestaande Proxy-functie. Zo kunnen gebruikers een port configureren voor nog meer controle over hun verbinding. Het is nog niet bekend of en wanneer de functie voor alle gebruikers uitgebracht wordt.

WhatsApp proxy instelligne
Een gedeelte van de instellingen. Bron: WABetaInfo

Met een proxy kunnen WhatsApp-gebruikers al een medium tussen hun apparaat en de servers van Meta instellen, bijvoorbeeld om een overheidsblokkade te omzeilen. Met de nieuwe instellingen kunnen gebruikers de gebruikte port voor media- en chatbestanden onafhankelijk instellen. Servers of proxyserverproviders kunnen bijvoorbeeld bepaalde restricties hanteren en met aparte adressen voor chatgegevens en media kunnen ook deze beperkingen vermeden worden, aldus WABetaInfo.

De website meldt daarnaast dat er een optie getest wordt voor extra Transport Layer Security. Hiermee wordt data tussen de gebruiker en de proxyprovider met encryptie beveiligd. WhatsApp biedt overigens standaard end-to-endencryptie voor chats. Tot slot zou de chatdienst in de bètaversie een deelfunctie testen waarmee gebruikers hun proxyinstellingen in het geheel kunnen delen.

Door Yannick Spinner

Redacteur

23-06-2023 • 14:01

22

Submitter: Anonymoussaurus

Reacties (22)

22
22
5
0
0
16
Wijzig sortering
Is TLS niet een standaard die letterlijk iedereen gebruikt? Wat wordt hier bedoelt met "extra Transport Layer Security"
Gewoon nog weer een tunnel om alles heen.
Ja waarom dan? Wat zou daar de toegevoegde waarde van zijn. Zoals ik ‘t lees is er dan een aparte TLS verbinding tussen client (whatsapp device) en proxy. Binnen deze TLS sessie zou je dan de gebruikelijke TLS sessie tussen Whatsapp en meta servers die er nu ook al is, maar dan getunneld over een http proxy ( de zgn CONNECT method)
Ja waarom dan? Wat zou daar de toegevoegde waarde van zijn.
Omzeilen van censuur.

China blokkeert whatsapp.com

Proxy draait buiten China op nietgeblokkeerdinchina.org

WhatsApp-client -> (buiten) TLS -> nietgeblokkeerdinchina.org -> (binnen) TLS -> whatsapp.com

Vrijwillige proxyhoster kan de WhatsApp-data niet inzien dankzij de binnenste TLS-tunnel die doorgaat naar whatsapp.com. Signal kan dit ook.

Zo'n TLS proxy draait standaard op TCP-poort 443. Doordat het standaard TLS betreft kan je het verkeer onderscheiden van normaal websiteverkeer, en met een reverse proxy (zoals HAProxy) het verkeer routeren naar waar het heen moet (eigen webservers indien plain text na decryptie buitenste TLS-laag, of doorsturen naar whatsapp.com indien na decryptie van de buitenste TLS-laag er nog een binnen TLS-laag gezien wordt)

Uiteraard zijn er voor WhatsApp meer servers dan enkel whatsapp.com. Dankzij SNI toegepast op de binnenste TLS-tunnel door de WhatsApp-client weet de proxy waar welke data waarheen doorgestuurd moet worden. Hiermee is het bijvoorbeeld mogelijk om zowel een Signal TLS proxy als een WhatsApp TLS proxy op hetzelfde IP-adres en dezelfde TCP-poort te draaien, naast eigen diensten.

Het nieuwsbericht noemt dat de TLS proxy nu een andere poort dan 443 kan gebruiken. Zo zou je het ook op poort 22 kunnen hosten. HAProxy kan met de juiste configuratie SSH-verkeer onderscheiden van TLS-verkeer. En zo zullen er nog wel meer manieren te zijn om het te obfusceren onder een bestaande poort met een normaal alom gebruikte dienst (IMAPS op 993, SMTPS op 465, FTPS op 990, etc.).

[Reactie gewijzigd door The Zep Man op 31 juli 2024 10:31]

Yep. Inderdaad een use case. Thanks
De Grote Chinese Vuurmuur wordt hier echt niet mee om de tuin geleid. Kleinere, incompetentere firewalls misschien wel, maar qua netwerkanalyse loopt China hier keihard op voor. Netwerkverkeer als WhatsApp wordt gecategoriseerd en als het afwijkt krijg je een aantal RST's terug en klaar is je verbinding. Wil je in China je verbinding levend houden, dan zul je uit een paar VPN's moeten kiezen waar de overheid een oogje voor dichtknijpt (al is het maar de vraag waarom ze dat doen voor die specifieke bedrijven, natuurlijk).

Signal lijkt onder andere voor Iran mensen opgeroepen te hebben proxy's te draaien. Wellicht dat Iranese gebruikers hiermee geholpen zijn.
Doordat het standaard TLS betreft kan je het verkeer onderscheiden van normaal websiteverkeer
Nou ja… niet aan de inhoud van de pakketjes. Als je naar het gedrag van de pakketjes kijkt (hoeveelheid, frequentie, vertraging, enz) kan je wel degelijk onderscheid maken ;). Dit vereist uiteraard wel specialistische software.
Wellicht om het moeilijker te maken om Deep Packet Inspection toe te passen.
Klopt, en WhatsApp gebruikt op zichzelf al TLS, maar nu wordt dit ook nog eens door de proxy ondersteunt (naast E2EE).
Klopt. TLS is de opvolger van SSL. SSL wordt effectief nergens meer gebruikt (of dat zou in elk geval moeten, gezien het niet meer als veilig wordt beschouwd)

Als je overigens een VPN-provider zoekt, is dat wat ze verstaan onder ‘military-grade’ of ‘bank-grade’ encryption. Het is niet gelogen, maar iedereen doet het. ;)

https://yewtu.be/watch?v=WVDQEoe6ZWY
Ik heb het stuk nog een keer gelezen en inderdaad volgens mij een compleet useless feature tenzij er organisatie zijn die hun proxy alleen via een TLS enabled proxy aanbieden. Ik ken ze niet, dat soort organisaties. Daarnaast ben ik ook benieuwd als deze organisaties bestaan of ze een private PKI gebruiken. En hoe gaat whatsapp daar dan mee om?
Je hoeft helemaal geen verkeer te ontsleutelen bij een TLS-proxy. Via het CONNECT-verb kun je een TLS-verbinding openen via een proxy, en het vereist extra werk van de proxy om daarmee te klooien. Dat kan over HTTP en over HTTPS, bijvoorbeeld.

MitM is zeker een nuttige feature van veel lokale tools, maar je kunt heel eenvoudig Squid of zelfs Nginx een HTTPS-certificaat geven en apparaten daarover te laten verbinden zonder je data in gevaar te brengen.

Er zijn wel degelijk bedrijven die met een TLS proxy werken. Sterker nog, veel van deze bedrijven doen ook nog eens aan het onderscheppen van TLS-verkeer, onder andere doordat ze van de wet verplicht zijn om alle data te ontsleutelen. In Amerika heb je dit bijvoorbeeld bij sommige financiële bedrijven.

In andere bedrijven wordt er een magische middlebox gebruikt om verdacht verkeer tegen te houden en malware te detecteren. Ik ben er geen voorstander van omdat ik eigenlijk in geen enkel bedrijf de IT-afdeling genoeg vertrouw om zulke gevoelige informatie te onderscheppen, maar aan de andere kant zie ik de voordelen wel. Als je je netwerk wil filteren, moet je dingen als SNI-sniffing toepassen (wat met domain fronting omzeild kan worden en wat over een paar jaar niet meer werkt) en veel ander verkeer valt helemaal niet meer te monitoren omdat ondersteuning ontbreekt. Dingen als DNS-over-HTTPS tegenhouden om een eigen DNS-filter af te dwingen en het scannen van mailbijlages is een leuk verhaal voor managers, al is dat natuurlijk geen betrouwbare manier om je netwerk te beveiligen omdat je er dan maar van uit gaat dat de bad guy standaardprotocollen gebruikt.

Toch zie je hier op Tweakers regelmatig mensen in paniek raken dat DNS versleuteld kan worden waarmee hun eigen filters worden omzeild, alsof dit al tien jaar geleden niet gewoon over HTTP gedaan werd door alles van advertentiebedrijven tot malwareboeren.

Het instellen van een proxy zit al lang in Android dus ik snap niet helemaal waarom WhatsApp die nodig zou hebben. Ik gok dat sommige proxy's niet met WhatsApp overweg kunnen (dit soort middleboxes zitten doorgaans vol met protocolbugs) en dat dit een workaround is.
Die proxy settings in Android zijn (op de eerdere versies na) echt zeer beperkt. De meeste apps negeren die volledig zonder root, je kunt het niet forcen. Maar oké, dat is licht offtopic, want het lijkt me dat WhatsApp gewoon kan kiezen om die instelling wél uit te lezen.
Precies, WhatsApp kan gewoon de proxy accepteren en doet dat volgens mij ook gewoon.

Het negeren van de proxy is inderdaad zeer ergerlijk, je moet allerlei lelijke hacks zoals transparante interceptie gebruiken wil je ze via een proxy laten lopen.

Dat komt soms ook gewoon door bugs, ik heb al één HTTP-framework voorbij zien komen waarvan de proxy-implementatie wel de hostname overneemt maar de poort op -1 laat staan, waarna je natuurlijk een gigantische exception krijgt. Kwaliteitje.
Ik heb bij meerdere bedrijven gewerkt waar ze dergelijke proxies gebruiken om niet-toegestane diensten te blokkeren.

Stel dat ik op een privé-servetje ergens in de cloud ‘Owncloud’ of zo zou draaien en dit is niet toegestaan vanwege policy xyz; dan is dit een relatief makkelijke manier om dit te blokkeren.
(( aangezien mijn netgebouwde cloud-instance echt niet op de standaard blokkeerlijsten staat ))
Het voordeel van een TLS-proxy in een applicatie instellen, is dat het verkeer dan al voor het OS in gaat al versleuteld wordt.

Uiteraard had de applicatie ook de instellingen kunnen overnemen en dan alsnog zelf versleutelen, maar nu kan je dus, indien nodig, via een niet-standaard proxy de deur uit. Dus stel dat je Android middels policies bepaalde instellingen krijgt, dan kan je die dus zelf voor WA negeren.
WhatsApp versleutelt het verkeer alleen al lang, ze zijn echt de dagen van plaintext XMPP al lang voorbij.

Je kunt er altijd en laagje tussen zetten natuurlijk, maar voor de veiligheid zal het niet zoveel toevoegen.
Voor de veiligheid niet, wel gedeeltelijk voor de privacy (( dus ‘dat’ je aan het WhatsAppen bent 😊))

Onder diezelfde noemer voegt een commerciële vpn-dienst ook niets toe aan veiligheid. Op DNS na (tenzij er DoH of zo gebruikt wordt) is al het verkeer van alle apps versleuteld.
Misschien, maar maakt het echt zoveel uit of je nu via SNI de hostname van WhatsApp lekt of dat je een proxy benadert die alleen WhatsAppverkeer doorlaat? In beide gevallen is het best duidelijk wat voor verkeer je precies stuurt.

Dat gezegd hebbende zou je natuurlijk WhatsApp op deze manier via Tor kunnen laten lopen op een manier die officieel ondersteund wordt, daar zou je nog wel een voordeel uit kunnen halen.
Daar heb je ook weer een valide punt.

Dat haalt in de basis niet zo veel uit. Hooguit als je een algemene proxy hebt? Of een soort “onbekende” privé-proxy in een cloud omgeving?

Dan ziet de tussenlaag alleen verkeer naar een webdienst in een cloudomgeving.
Ik zat zelf hardop te denken waarom WhatsApp twee aparte poorten gebruikt voor berichten en media, maar dat zit zo:

WhatsApp gebruikt natuurlijk aparte protocollen voor media en berichten. Berichten maken doorgaans gebruik van Jabber over HTTP(S) terwijl media HTTPS gebruikt. Doordat dit andere protocollen zijn worden er andere poorten gebruikt, vandaar dat er ook twee velden zijn. Zie hier voor meer informatie over de architectuur (WhatsApp proxy code is open-source): https://github.com/WhatsA...atsapp-proxy-architecture
Wanneer je dit moet gebruiken in WhatsApp, dan is het waarschijnlijk tijd om over te stappen op Signal.

Op dit item kan niet meer gereageerd worden.