Skip to end of metadata
Go to start of metadata


Key functionality of the accountability is to screen all network traffic to verify that the internet is used in an accountable way. This is particularly challenging for HTTPS sites, because the conversation over this protocol is encrypted, with the objective to make interception (screening) of the data impossible. This page describes the few options that (still) exist to intercept HTTPS traffic.

SSL stripping

In this approach, all traffic from the device running the accountability app is routed through a proxy. That proxy creates a secured connection (HTTPS) between the proxy and the origin server, but establishes a regular HTTP connection between the device and the proxy. That way, all traffic can be screened.

This approach is known as SSL stripping and it is used in a downgrade attack. The internet community has formulated an answer through HTTP Strict Transport Security  (HSTS). Quote from Wikipedia:

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which is necessary to protect secure HTTPS websites against downgrade attacks, and which greatly simplifies protection against cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

HSTS is not widely implemented yet, so SSL stripping could be used as a screening approach for certain sites for limited time, but it brings a severe risk to the users (traffic is not encoded) and, given the prevention measures being implemented, it is not worth the investment.

Man in the middle

The infrastructure for this approach is similar to the one for SSL stripping. The traffic is again routed through a proxy, but now the proxy sets up HTTPS at both sides. Between the proxy and the origin server, the connection is secured through the certificates of the origin server but the connection between the device and the proxy is secured with certificates of Yona. That allows us to decrypt the data and screen it.

This approach is known as a Man-in-the-middle attack. The internet community has formulated a generic answer to it by means of  Public Key Pinning Extension for HTTP (RFC 7469). This was recently standardized (April 2015) and will replace the already existing nonstandard implementations for certificate pinning (aka SSL pinning), where applications and browsers come with a set of hard coded certificates linked to sites.

At first glance, this standard seems to prevent the development of a product that intercepts HTTPS traffic, but fortunately is not the case. The RFC defines a mechanism that allows users to load a certificate in their trust store, which can be used by a "man in the middle":

It is acceptable to allow Pin
Validation to be disabled for some Hosts according to local policy.
For example, a UA may disable Pin Validation for Pinned Hosts whose
validated certificate chain terminates at a user-defined trust
anchor, rather than a trust anchor built-in to the UA (or underlying

The objective of this mechanism is to enable debugging (e.g. Fiddler) and to allow content filtering in enterprise scenarios (see the explanation given here). The RFC describes it as an option, so browsers do not have to implement it, but the good news is that at least Chrome supports it (see the Chrome security FAQ). A detailed technical description of a man-in-the-middle proxy is available here on the Internet.

Device level interception

It is possible to intercept the traffic before the request is encrypted or after the response has been decrypted, but only for selected applications. A generic approach does not seem to be possible (Even the Parental Controls Internet content filter of Apple on Mac OS is not capable of filtering the content, see the HTTPS note here.). All browsers seem to have their own implementations: Firefox has provisions, Internet Explorer integrates with Windows Parental Controls and  Chrome has supervised Users.


The man-in-the-middle approach is a viable solution. RFC 7469, designed to prevent a man-in-the-middle attack contains a specific provision to enable content filtering in a way Yona intents to provide.


  • No labels


  1. I assume these approaches work only for browser-based traffic, as you need

    • to setup a proxy on the device through which the traffic passes
    • to redirect to yona in order to perform the checking

    I would expect that apps make it even harder

    • they probably use certificate pinning
    • they may have their own protocol


  2. And I see another generic problem with this interception approach, especially when browsers show that to the users with the broken lock image or something like that.

    It may influence the user's behavior when dealing with malicious sites as well, in the sense that if they see a broken lock on the internet banking site, they may assume it is yona in between. But it may be the hacker.

    This human-behavior aspect needs attention as well.

  3. Herman van Rhijn mailde het volgende:

    Voor zover wij weten zal zowel HSTS als HPKP door browsers niet worden gebruikt wanneer een CA certificaat is geïmporteerd in de Trusted Root Certificate store op de client.

    Heb je geen certificaat dan heb je wel een probleem:

    Door HSTS zal een gebruiker niet meer langs de certificaat waarschuwingen kunnen komen

    Door HPKP zal een gebruiker geen site kunnen bezoeken waarvan het SSL certificaat werd “gepind”.


    1. Ik heb het relevante deel van RFC6797 (over HSTS) doorgelezen en kan nergens vinden dat browsers HSTS zullen negeren als er een CA certificaat geïmporteerd is. Het is ook moeilijk voor te stellen hoe dat zou moeten werken, omdat bij SSL stripping er voor de browser geen certificaat meer in het spel is.

      De volgende paragraaf uit sectie 7.1 is nog interessant:

      Other mechanisms, such as a client-side pre-loaded Known HSTS Host list, MAY also be used; e.g., see Section 12 ("User Agent Implementation Advice").

      Ik dacht dat het mogelijk zou zij dat browsers die de site nooit via SSL "gezien" hadden, vatbaar zouden blijven voor SSL stripping. Als browsers met een lijst van bekende HSTS hosts geleverd worden, kan dat probleem voor die set van hosts voorkomen worden. Ik moet de HPKP RFC nog lezen, maar ik had de gedachte dat vast opgestelde PCs die altijd het filter het internet op gaan, HPKP zouden kunnen omzeilen door vanuit het filter een HPKP header te genereren. Als ze daar ook preloading promoten, dan gaat dat ook niet werken.

      Vanavond hoop ik HPKP RFC door te lezen en daar ook op te reageren.

    2. Weer even genoten van een kop zwarte koffie en een goede RFC (smile)

      Wat Herman zegt klopt voor HPKP. De methode voor HSTS willen we toch niet gebruiken, dus dat de uitspraak daarover niet lijkt te kloppen is niet belangrijk.

      Dit is het relevante statement uit de RFC (2.6 Validating Pinned Connections)

      It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform).

      Dit is wat is geïmplementeerd voor Chrome, zie de security FAQ:

      Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

      De motivatie is als volgt: 

      We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should.

      In het geval van Yona is het niet zo dat het apparaat en de proxy onder de macht van dezelfde beheerder vallen, maar het is legitiem om de gebruiker te vragen de door hem gekozen proxy te vertrouwen en daarvoor een certificaat te installeren.

      Als ik het goed begrepen heb is het op dit moment niet verplicht voor mensen achter SmoothWall om het filter te installeren. Als HPKP actief wordt zal dat wel verplicht worden. Verder blijft het afwachten of alle browsers (en andere apps!) een methode ala Chrome zullen kiezen. Ik verwacht dat wel, omdat de door Google geschetste scenario's inderdaad legitiem zijn, zoals Chris Palmer hier zegt.

      Net als bij HSTS kunnen browsers er ook voor kiezen de pins in de browser op te slaan:

      2.2.1 Establishing a given host as a Known Pinned Host

      2.  Through other mechanisms, such as a client-side pre-loaded Known Pinned Host List.

      En ook 2.7 Interactions With Preloaded Pin Lists

      UAs MAY choose to implement additional sources of pinning information, such as through built-in lists of pinning information. Such UAs should allow users to override such additional sources, including disabling them from consideration.

      The effective policy for a Known Pinned Host that has both built-in Pins and Pins from previously observed PKP header response fields is implementation-defined.

      Weer terug naar de hoofdzaak: de methode van SmoothWall is dus in principe ook bruikbaar voor Yona. De enige zorg die ik nog heb is dat ik niet weet hoe met met de usability zit: hoe lastig is het op Android, iOS en Windows om een certificaat toe te voegen? Als dat acceptabel is wordt het voor ons mogelijk een VPN-gebaseerde oplossing te implementeren voor alle apparaten (Android, iOS en Windows). Aan de serverkant is het niet de goedkoopste oplossing: al het verkeer komt door de VPN tunnel, dus er zal voldoende capaciteit moeten zijn om een snelle verbinding te waarborgen.

      Als jullie het met die conclusie eens zijn wil ik de wiki pagina's navenant aanpassen.

      1. Dus als ik het goed begrijp gaat het als volgt werken (als aan de voorwaarden voor ease of use en dergelijke is voldaan):

        • alle netwerkverkeer van alle browsers en alle devices gaat via een VPN van Yona.
        • De gebruiker moet een Yona certificaat accepteren voor de Yona MITM server (http/https), tijdens de aanmelding bij Yona.
        • Yona stuurt het request door naar de uiteindelijke site. Op een parallel spoor gaat het request naar de filtering service die bepaalt of het goede of foute sites betreft
        • De route via accessibility gaan we dan niet

        Vragen die overblijven zijn:

        1. werkt het voor alle browsers?
        2. wat gebeurt er als mensen verbinding moeten maken met andere VPN-gebaseerde netwerken, zoals school of bedrijf?
        3. is het gemakkelijk uit te schakelen?

        Groeten, Rine



        1. Dat heb je goed begrepen (op het kleine puntje na dat het certificaat niet nodig is voor het bezoeken van http sites).

          De route via accessibility gaan we dan niet

          Nee. Het is trouwens grappig om te zien dat NetProtector voor iOS waarschijnlijk dezelfde benadering gebruikt die wij hier nu bespreken:

          We do not use MITM for VPN connection. We need to have a complete VPN setup in place so that all device traffic is sent to our VPN server. We do this by installing a VPN profile on the device (including certificates for HTTPS and VPN) so that the device connects to our VPN server whenever internet is required. After decryption by the VPN server, the traffic is forwarded to the respective services on the NetProtector server for further analysis. Also dynamic filtering (using our neural network solution) is included for HTTPS service.

          Aan de ene kant zeggen ze dat ze geen MITM gebruiken, maar aan de andere kant moet de gebruiker wel een certificaat voor HTTPS installeren en decrypten ze wel de het verkeer. We moeten het even vragen, maar het lijkt er sterk op dat ze wel MITM doen.

          Wat betreft je vragen:

          1. werkt het voor alle browsers?

          Waarschijnlijk wel, maar we moeten het uitzoeken. Zoals ik al zei: het blijft afwachten of alle browsers (en andere apps!) een methode ala Chrome zullen kiezen, maar het lijkt me waarschijnlijk.

          2. wat gebeurt er als mensen verbinding moeten maken met andere VPN-gebaseerde netwerken, zoals school of bedrijf?

          Ik weet er niet veel van, maar ik vermoed dat dan de Yona VPN er uit moet. Ik weet niet of hij dan automatisch weer op de Yona VPN terug kan komen. Ik begreep dat Jan Bosch of Ron van der Wijngaard al eens naar VPN op Android en/of iOS gekeken hadden. Misschien kunnen die hier iets over zeggen.

          3. is het gemakkelijk uit te schakelen?

          Volgens Jan of Ron kan je heel gemakkelijk automatisch een VPN opzetten. Ik weet niet of je deze als gebruiker weer makkelijk uit kan zetten. Een andere interessante vraag is of je goed kunt detecteren dat de VPN uit staat, zodat je de buddy kan informeren.

          1. Ik had al eerder gezien dat producten als Cloak een goede experience op iOS geven. Ik heb er geen ervaring mee, maar mogelijk zijn de iPhone gebruikers onder ons hiermee bekend?

            Voor Android zijn er blijkbaar ook veel goede VPN producten, zoals een snelle google liet zien.

      2. Bert, ik snap de link naar VPN nog niet helemaal. Heb je die nodig om via de man in de middle te gebruiken?


        1. Inderdaad. Via de VPN leid je al het verkeer over de Yona servers en daar zorg je er voor dat een proxy de verbinding onderschept.

          1. Hou hier nog rekening met het volgende scenario:

            Een gebruiker zit thuis via Wifi verbonden met internet. De app is actief en het VPN dito.
            De gebruiker gaat op stap - Wifisignaal verdwijnt en er wordt omgeschakeld naar 3G/4G.

            De VPN verbinding zal worden verbroken en moet opnieuw worden opgebouwd.
            In het verleden (jullie hebben daarvan documentatie gekregen van Bert Jan) was dit in ieder geval op Android een probleem. We hebben toen wel een 3rd party oplossing gezien die in staat was het VPN opnieuw op te bouwen, Zonder die add-on was er een handmatige actie van de gebruiker nodig om de VPN weer actief te krijgen.
            Kan zijn dat (we zijn inmiddels een aantal jaren verder) dit probleem niet meer speelt - maar het leek me goed  dit toch even te noemen,.

  4. VPN

    Mijn ervaring is dat vpn oplossing behoorlijk gesmeerd kan lopen en dat vanuit de app een een vpn profile installeert. Voorbeelden waar ik ervaring mee heb (alleen iOS):

    1. Onavo ( heeft een data "bespaar" app en een VPN app voor iOS, maar ook voor Android.
      1. Onavo Extend Diensten
      2. Free VPN - Onavo Protect Zakelijk
    2. Cisco VPN: gebruiken wij zakelijk voor vpn.
      1. Cisco AnyConnect Zakelijk

    Volgens mij wou Netprotector OPENVPN als basis pakken en er zijn tal van VPN "oplossingen" in de Appstore en vaak ook juist om privacy te beschermen en blocked sites te omzeilen. Misschien is kijken of dit juist ook niet weer een manier is om ook yona vpn te omzeilen.


    Volgens mij hebben we het ook al wel eens over Accessibility gehad. Is er nog gekeken of we hier wat mee kunnen?



    1. Heb je ook ervaring met het wisselen van VPN? Bijvoorbeeld van Onavo naar Cisco? En gaat hij dan automatisch terug naar Onavo?
      Het lijkt me dat je in een app wel kunt zien of er een VPN actief is, misschien ook wel welke. In het beste geval kan je een event krijgen bij VPN wissels. Op die manier kan de Yona (is iets anders dan Yoga ;)) app de buddy informeren als de VPN wordt uitgezet. Ook al is het dan makkelijk, dan lijkt het me geen punt, als tenminste de VPN weer automatisch bij Yona terugkomt.

      1. Nee, geen ervaring met wisselen tussen Cisco en Onavo, maar kan ik even testen. Onavo werkt alleen bij Cellular Data en bij WIFI niet en deze omschakeling loopt vloeiend. Met Onavo heb ik wel ervaring met deleten van profile via settings, dan geeft de app gelijk aan dat deze opnieuw geïnstalleerd moet worden. (Fijn die autosuggest (wink) van confluence, heb het even gecorrigeerd:)