Accesso crittografato in siti web di partiti politici

Visto l’interesse per l’argomento, riassumo lo stato dell’accesso protetto da crittografia di 5 siti web di partiti politici.
Di questi, solo il sito web del Partito Democratico ha un accesso crittografato in maniera sicura. Accettabile con riserva.
Il Movimento 5 Stelle ha un ottimo sistema, Rousseau, ma non tutto è in sicurezza. Fratelli d’Italia, Forza Italia e Lega Nord, totalmente assente.

Unico pensiero politico da parte mia (prendetelo in maniera costruttiva): mi aspettavo maggiore cura dal Movimento 5 Stelle considerando che la rete è il suo cavallo di battaglia.

Immaginate ad esempio che un utente visiti quei siti web da un accesso pubblico (wifi pubblico, albergo, aeroporto etc). Un attaccante potrebbe:

  • intercettare in chiaro le credenziali (tra cui in chiaro le passwords, spesso riutilizzate).
  • reindirizzare la richiesta (alterando il form html) verso siti web malevoli.
  • alterare la risposta di ritorno, inserendo un javascript che funziona da keylogger in modo da intercettare poi ogni possibile interazione anche futura.

Questi ESEMPI di potenziali attacchi valgono per tutti, PD compreso, dato che non ha attivato alcuna forzatura alla versione sicura nei form di credenziali.

La maggior parte di produttori di browser hanno piani a lungo termine per l’abolizione delle connessioni in chiaro (es. Firefox), e i primi passi imminenti sono l’implementazione di warning di sicurezza (es. FireFox, Chrome).

Chrome pubblico usato dalla gente comune è la versione 55. La versione che notificherà che i siti web sopra-citati sono insicuri sarà la 56. E’ davvero molto imminente, imho.


Movimento 5 Stelle / Beppe Grillo

Rousseau https://rousseau.movimento5stelle.it è ottimamente configurato.
Certificato hash algorithm sha256 ok, rating ssl-labs: A+ altissimo (il massimo, abbastanza raro),
ottimo l’uso di HSTS che garantisce a monte che il sito sia interamente sotto crittografia. Versione web-server nascosta.

Una pesante pecca: l’iscrizione punta ad un’altra macchina, malmessa a livello di configurazione:

  • Riporta un vecchio Apache/2.2.15, che ha parecchie vulnerabilità note.
    Può essere che alcune vulnerabilità siano chiuse (ad esempio come i package debian in repo stable su distro LTS), non ho investigato sulle singole vulnerabilità.
    Dei penetration-testing sono più impegnativi di questa mia ricerca da tempo libero.
  • Restituisce un certificato scaduto da diversi giorni.
  • common-name errato (www.beppegrillo.it), che porta a una pagina web inesistente (404).
  • hash algorithm sha1, male.
  • Vulnerabile a POODLE e weak cipher.
  • Scelta incredibile. Di solito è accettabile avere un sito in chiaro con la sezione di autenticazione (login/register) sotto crittografia. Ma avere Rousseau protetto e registrazione in chiaro è tutto il contrario.

L’iscrizione quindi è obbligatoriamente in chiaro, perchè usare un accesso scarso di rating ssl-labs: T equivale a non usarlo.

Vedo ottime premesse, a spanne basta che il team di Rousseau prenda in carico anche l’altra macchina malconfigurata.


Partito Democratico

Buono, non ottimo.

Accesso crittografato https://www.partitodemocratico.it/ è OK.

La pecca è che la versione in chiaro funziona, potrebbe redirigere direttamente alla versione crittografata, o meglio ancora implementare HSTS come Rousseau.
E’ una pecca importante perchè la versione di login funziona anche da accesso non crittografato.
Obiettivamente se un accesso è insicuro e la versione sicura esiste, non è possibile venire incontro alla vita agli utenti che non conoscono la differenza o manco sanno che possono scegliere?

Piccola pecca, https://partitodemocratico.it restituisce ERR_BAD_SSL_CLIENT_AUTH_CERT. Pare solo mal-configurato il terzo livello “www.”.

Certificato SSL, ok per sha256. ssl-labs: B migliorabile, degli accessi con cipher weak andrebbero chiusi. Rousseau è configurato meglio.

Pare usino Apache 2.2.22 su FreeBSD. Non conosco decentemente FreeBSD.

Curiosità: Dal sito web, cliccare Accedi porta a un url da 3228 caratteri/bytes. Tutti fondamentali eh. (ironico).


Fratelli d’Italia

In http://www.fratelli-italia.it praticamente l’accesso cifrato non esiste.

Tesseramento e login solo in chiaro.

La versione cifrata del tesseramento mostra un 503 Service Unavailable, con un certificato self-signed che non corrisponde neanche come common-name.

ssl-labs: F. Vulnerabile al POODLE attack, weak cipher, etc.

Se non altro, nascondono che software web-server usano.


Forza Italia

http://www.forzaitalia.it è solo in chiaro, l’accesso crittografato per il sito principale non risponde.

La login è in chiaro.
L’accesso crittografato per il login spara pagina non trovata (HTTP 404).
Certificato SSL self-signed, scaduto 3 anni fa. 1024 bits. In pratica come se non ci fosse.

ssl-labs: F Tutto weak. Due diverse vulnerabilità, POODLE e CVE-2016-2107.

Praticamente l’accesso crittografato non esiste.

Apache/2.2.25 Amazon.


Lega Nord

http://www.leganord.org/ tutto in chiaro. L’accesso crittografato non esiste.

Apache 2.4.10 su Fedora.

https://www.beppegrillo.it e disclosure

Recentemente ho notato che il certificato SSL di https://www.beppegrillo.it è scaduto.

La cosa mi ha incuriosito perchè quel sito web è uno dei più frequentati d’Italia, e mi è parso strano che nessuno nell’arco di 5 giorni si sia indignato di dover inserire una password in una connessione in chiaro (esempio).
Anche perchè la figura di m. è imminente, le beta o candidate-release di browser moderni mostrano degli avvisi espliciti laddove è richiesta una password in una connessione non cifrata. Vedi ad esempio https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/

Ieri sera l’ho fatto notare a Paolo Attivissimo via Twitter:

Poco dopo, Paolo ha twittato:

Immediatamente ho precisato che un certificato SSL non scaduto per il dominio www.beppegrillo.it esiste, ma non è configurato sulla macchina relativa:

Claudio d’Angelis mi ha fatto notare che l’approccio non è proprio professionale, dato che normalmente il protocollo non dovrebbe determinare il tipo di contenuti, mentre invece pare evidente che il blog sia necessariamente in chiaro, e la crittografia riservata ad altro (non so di più, mai frequentato il sito di Grillo).

A questo punto ho indagato (parolone…) altri 5 minuti (neanche), e ho notato che il webserver risponde fornendo informazioni sulla versione di Apache installata

Non che questo sia grave di per sè, ma di solito i professionisti evitano di fornire questo genere di info per rendere almeno un pelo più difficile la ricerca di vulnerabilità.

Un veloce controllo su SSL-Labs ha evidenziato vulnerabilità note (PODDLE), cipher weaks e altre varie.

Cosa prevedibile con un Apache 2.2.15, che è un po’vecchiotto. POODLE confermato anche dallo scan online di Comodo.

Più di una persona su Twitter fa notare che il sito di gestione del Movimento è su un’altra macchina, https://rousseau.movimento5stelle.it/ , che a una prima occhiata pare ben configurata.
Ma obiettivamente in questo settore non è che se un qualcosa è obsoleto lo si abbandona senza aggiornamenti, anche perchè se quell’accesso presenta vulnerabilità da remote-code-execution, significa accesso all’intera macchina (ed eventualmente al database annesso).

E qui arriviamo al motivo di questo riassunto.
Mi preme precisare che ho usato il termine colabrodo perchè è evidente la situazione, ma NON ho MAI detto che è una situazione grave.
Mi ritengo un professionista nel mio settore (sicurezza IT), ma qui sono sempre rimasto a livelli di chiacchere da bar.
Stabilire la gravità di noncuranze richiederebbe un’analisi più accurata, dei penetration-testing, notifiche private, disclosure concordate etc.
Potrebbe anche essere che la macchina in questione è solo un vuoto reverse proxy o un load-balancer a una macchina di backend meglio configurata, per dire.

Estote parati! (@lastknight docet)

(Editato in seguito per correggere il mio italiano..)

Sample ODS video

I rendered with POV-Ray (using my approach) a sample 360 degree, omnidirectional, stereo video (top/bottom).
Can be used for stress testing VR Video players, HMD etc.

It’s a 120 frame animation, loopable. It mean one seconds at 120 FPS (for example PSVR), 1.25 seconds at 90 FPS (Oculus Rift, HTC Vive), etc.

YouTube Preview:

Real plain preview:

It took around 4 days for rendering on my i7 with eight cores.
Every frame have 7680 x 7680 pixels resolution (Stereo top/bottom), around 32 MB PNG each.
I encoded it in different FPS and resolution. As explained in my other post about ODS, x264 don’t support highest framerate at highest resolution.

ffmpeg command-line encoding:

ffmpeg\bin\ffmpeg.exe -framerate 60 -i sample%03d.png -c:v libx264 -preset veryslow -vf scale=1280:720 -x264-params crf=18 -c:a aac -strict experimental preview.mp4

Download links

Image:
Single shot image, 7680 x 7680 pixels (9370 KB)
Videos:
x264 – 30 FPS – 4K UHD
x265 – 60 FPS – 4K UHD
x265 – 90 FPS – 4K UHD
x265 – 90 FPS – 4K DCI
x265 – 90 FPS – 8K
x265 – 120 FPS – 8K

POV-Ray source code: .pov, .ini.

Omni­directional stereo (ODS) with POV-Ray

Omni­directional stereo (ODS) is a projection model for stereo 360 degree videos
It’s designed for VR viewing with a head­mounted display (HMD).
More information here.

I developed and tested for fun an approach for raytracing, open-source POV-Ray software.

How to render

Currently (2016-03-11), render ODS image require an alpha version of POV-Ray, that support user_defined camera. Download from here
Or use my POV-Ray fork. More information on this below.

With POV-Ray official (Alpha),
Use the following code for an ODS top-bottom (left eye on top, right eye on bottom):

// ODS Top/Bottom - Docs: https://www.clodo.it/blog/?p=80
#declare odsIPD = 0.065; // Interpupillary distance
#declare odsVerticalModulation = 0.2; // Use 0.0001 if you don't care about Zenith & Nadir zones.
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree. 

camera {
  user_defined
  location {
    function { odsLocationX + cos(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(sin(select(y, 1-2*(y+0.5), 1-2*y)*pi), odsVerticalModulation))*select(-y,-1,+1) }
    function { odsLocationY }
    function { odsLocationZ + sin(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(sin(select(y, 1-2*(y+0.5), 1-2*y)*pi), odsVerticalModulation))*select(-y,-1,+1) * odsHandedness }
  }
  direction {
    function { sin(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -select(y, 1-2*(y+0.5), 1-2*y) * pi) }
    function { sin(pi / 2 - select(y, 1-2*(y+0.5), 1-2*y) * pi) }
    function { -cos(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -select(y, 1-2*(y+0.5), 1-2*y) * pi) * odsHandedness }
  }
}

Use the following code for an ODS side-by-side:

// ODS Side-by-Side - Docs: https://www.clodo.it/blog/?p=80
#declare odsIPD = 0.065; // Interpupillary distance
#declare odsVerticalModulation = 0.2; // Use 0.0001 if you don't care about Zenith & Nadir zones.
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree. 

camera {
  user_defined
  location {
    function {  odsLocationX + cos(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(sin((1-(y+0.5))*pi), odsVerticalModulation))*select(x,-1,1) }
    function {  odsLocationY }
    function {  odsLocationZ + sin(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(sin((1-(y+0.5))*pi), odsVerticalModulation))*select(x,-1,1) * odsHandedness }
  }
  direction {
    function {  sin(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) }
    function {  sin(pi / 2 - (1-(y+0.5)) * pi) }
    function {  -cos(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) * odsHandedness }
  }
}     

Use the following code for single eye rendering:

// ODS Single Eye - Docs: https://www.clodo.it/blog/?p=80
#declare odsIPD = 0.065; // Interpupillary distance     
#declare odsVerticalModulation = 0.2; // Use 0.0001 if you don't care about Zenith & Nadir zones.
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree.              
#declare odsEye = -1; // -1 for Left eye, +1 for Right eye

camera {
  user_defined
  location {
    function {  odsLocationX + cos(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(sin((1-(y+0.5))*pi), odsVerticalModulation))*odsEye }
    function {  odsLocationY }
    function {  odsLocationZ + sin(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(sin((1-(y+0.5))*pi), odsVerticalModulation))*odsEye * odsHandedness }
  }
  direction {
    function {  sin(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) }
    function {  sin(pi / 2 - (1-(y+0.5)) * pi) }
    function {  -cos(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) * odsHandedness }
  }
}                               

Caveats

  • Camera Direction is actually not supported. It’s always look_at<0,0,1>. You can use the odsAngle parameter for a rotation (degree) around Y axis.
  • Zenith & Nadir Zones
    Base ODS algorithm have spiral/singularities towards the zenith and nadir points.To avoid that, i modulate the stereoscopic eye separation such that it begins at normal eye separation near the horizon, and is smoothly decreased, reaching zero by the time either the zenith or nadir points on the polar axis are visible to the user, producing a monoscopic image.

    I use this formula:

    where 0.02 it’s the odsVerticalModulation and 0.065 the default IPD. Play with this value to understand how IPD are reduced near the Zenith (x:-0.5) and Nadir (x:0.5).

    In general, it’s recommended to avoid objects at zenith & nadir points, and use a odsVerticalModulation near 0 (0.0001), to obtain a perfect IPD / 3d effect.
    If you have objects at zenith & nadir points, use a odsVerticalModulation near 1 can be a good compromise.

    Other approach:
    Domemaster3D (Shader for 3DS Max, Mata, Softimage etc) recommend a texture to reduce the effect. link

    SolidAngle/Arnold use mixed approach. link

    Another kind of modulation: link

Best practice

  • Objects should remain at least 60cm from the camera (relative to an IPD of 6.5cm).
    Use this POV-Ray code to check (it’s auto adapt based on IPD):

    sphere
    {
      <odsLocationX,odsLocationY,odsLocationZ>, 0.6*odsIPD/0.065
      pigment
      {
        color <1,0,0>
        filter 0.97
      }
      hollow
    }
    
  • Objects appearing directly above or below the camera should remain at least 3.5m from the camera (relative to an IPD of 6.5cm).
  • Antialiasing is very very very important on VR headset.

Recommended Resolutions

I recommend, at least for the current (year 2016) generation of VR headset (GearVR, Oculus Rift, HTC Vive), at least 6480 x 6480 pixels in top/bottom for static images. For videos, see below.

Resolution must have 2:1 aspect ratio (standard equirectangular), that become 4:1 for side-by-side or 1:1 for a top-bottom.

TL;DR;
It’s difficult to estimate a good resolution.
VR headset do a distortion for lenses, any every VR headset can have different lenses, different FOV, different panel resolution etc.

The GearVR for example has a 90° FOV on a 2560×1440 panel, but the center pixel covers 0.06° after distortion. This value is sometime called “pixel coverage” or “pixel density” or “pixel per display pixel” or “eye buffer scaling”. So, for the GearVR, 0.06° pixels means we need 360/0.06 = 6000 pixels to cover one monoscopic turn.

Rendering Animation/Video

This is actually problematic.

In theory, the resolution must be at least as explained above for images.

Any VR headset require a high frame-rate to avoid nausea.

  • Oculus Rift DK2 (Development Kit 2): 75 FPS
  • Oculus Rift CV1 (Customers Version 1): 90 FPS
  • HTC Vive: 90 FPS
  • Sony Playstation PSVR : 120 FPS

In general, future-generation VR headset: expected 120 FPS

But H264 don’t have any level profile compatible with this kind of resolution.
Also HEVC/H265 have the same problem.

But we also need a coded that is hardware-accelerated to obtain the high FPS requested, and generally only H264/H265 are optimized for this.

VR Players

Virtual Desktop – There isn’t any option about side-by-side vs top-bottom, it simply detect it from the aspect ratio: 4:1 for side-by-side, 1:1 for top/bottom.

MaxVR

Both player can’t reproduce H265 high resolution videos.

My POV-Ray fork on GIT-Hub

With a POV-Ray builded from my fork, you can simply use a spherical camera:

camera
{             
  spherical   
  //ipd 0.065
  ods 4 
  //ods_angle 0
  //ods_modulation 0.2
  //ods_handedness 1
  location <0,0,0>  
}             
  • ods: 0 for monoscopic image, 1 for left eye only, 2 for right eye only, 3 for side-by-side, 4 for top/bottom. 0 is default. 4 recommended.
  • Other parameters ipd, ods_angle, ods_modulation and ods_handedness are the same of the user_defined approach param described above.

Interesting Links

Kudos

Many, many thanks to:

Christoph Lipka, William F Pokorny, Jaime Vives Piqueres from POV-Ray newsgroup.
Joan from Oculus Forum.
Jakob Flierl (checkout is GIT-Hub repo about ODS).

Examples of rendering

Some example of rendering (6480 x 6480 pixels, Top-Bottom).

Mirrors – I made this

——————
Stacker Day – POV-Ray sample scene adapted for ODS

——————
Fractals 1 – POV-Ray sample scene adapted for ODS

——————
Fractals 2 – POV-Ray sample scene adapted for ODS

——————
Wineglass – POV-Ray sample scene adapted for ODS

——————
Axis – Test reference

I also rendered a sample video that can be used for stress-testing of VR video players.

QUICKRES.INI

Reference resolutions for POV-Ray quickres.ini

[ODS TB Quick Test - 512 x 512]
Width=512
Height=512
Antialias=Off

[ODS TB Test - 1024 x 1024]
Width=1024
Height=1024
Antialias=Off

[ODS TB Minimum - 3600 x 3600]
Width=3600
Height=3600
Antialias=On
Antialias_Threshold=0.3

[ODS TB High - 6480 x 6480]
Width=6480
Height=6480
Antialias=On
Antialias_Threshold=0.3

[ODS TB Ultra - 12288 x 12288]
Width=12288
Height=12288
Antialias=On
Antialias_Threshold=0.3

[ODS TB 1440p - 2560 x 1440]
Width=2560
Height=1440
Antialias=On
Antialias_Threshold=0.3

[ODS TB UHD-1 2160p - 3840 x 2160]
Width=3840
Height=2160
Antialias=On
Antialias_Threshold=0.3

[ODS TB DCI 4K - 4096 x 2160]
Width=4096
Height=2160
Antialias=On
Antialias_Threshold=0.3

[ODS TB 8K UHD - 7680 x 4320]
Width=7680
Height=4320
Antialias=On
Antialias_Threshold=0.3

[ODS LR Minimum - 7200 x 1800]
Width=7200
Height=1800
Antialias=On
Antialias_Threshold=0.3

[ODS LR High - 12960 x 3240]
Width=12960
Height=3240
Antialias=On
Antialias_Threshold=0.3

[ODS LR Ultra - 24576 x 6144]
Width=24576
Height=6144
Antialias=On
Antialias_Threshold=0.3
[ODS LR Low - 7200 x 1800]
Width=7200
Height=1800
Antialias=On
Antialias_Threshold=0.3

[ODS LR Normal - 12960 x 3240]
Width=12960
Height=3240
Antialias=On
Antialias_Threshold=0.3

[ODS LR High - 24576 x 6144]
Width=24576
Height=6144
Antialias=On
Antialias_Threshold=0.3

[ODS TB Low - 3600 x 3600]
Width=3600
Height=3600
Antialias=On
Antialias_Threshold=0.3

[ODS TB Normal - 6480 x 6480]
Width=6480
Height=6480
Antialias=On
Antialias_Threshold=0.3

[ODS TB High - 12288 x 12288]
Width=12288
Height=12288
Antialias=On
Antialias_Threshold=0.3

[ODS TB YouTube - 3840 x 2160]
Width=3840
Height=2160
Antialias=On
Antialias_Threshold=0.3

RGB Bulb Review

I’m testing different RGB bulb in my home automation environment, to research the best bulb in the market.
I will update this post with my other research and with people comments.

Short review, current winner: Aeon Labs Bulb.


Philips Hue

Website: http://www.meethue.com
Protocol : ZigBee

Pros:

-A lot of app for it

Cons:

– Only HSB colors, difficult to set a precise RGB color.
– Only 3 values for colors: Hue, Saturation and Brightness.
– Poor colors quality. Read the BravoRomeo review here.
I can’t understand the difference between yellow and green with my Philips Hue.
– Slower, slower reaction when changing colors. For example if i set a sequence of 9 colors (without fade), it took around 3 seconds to do all.

———————-

Aeon Labs Bulb Gen5

Website: http://aeotec.com/z-wave-led-lightbulb
Protocol: ZWave
ZWave SwitchColor CC version: 1

Pros:

– A lot of led
– 5 values for colors: RGB + Warm White + Cold White
– True, exact RGB colors
– Faster reaction to colors. For example if i set a sequence of 9 colors (without fade), it took around a fraction of second to do all.

Cons:

– It seems that don’t support fade between two arbitrary RGB color. It’s limited to simply preset of effects like rainbow.

———————-

Zipato RGBW bulb – rgbwe27zw.eu

Website: http://www.zipato.com/default.aspx?id=24&pid=81&page=1&grupe=
Protocol: ZWave
ZWave SwitchColor CC version: 1

Pros:

– 5 values for colors: RGB + Warm White + Cold White
– True, exact RGB colors
– Faster reaction to colors. For example if i set a sequence of 9 colors (without fade), it took around a fraction of second to do all.

Cons:

– Don’t support any kind of fade or effects. Confirmed by their support.

Hotmail and Gmail use blacklists of entire subnets for a single involved IP? Unbelievable

A mail to me from Leaseweb:

Dear sir, madam,

It appears you are hosting a TOR node on your LeaseWeb IP address [omissis].
This has resulted in the block of a (part) LeaseWeb IP subnet. (/24)
As the subnet is added on the SECTOOR blacklist (http://www.sectoor.de/tor.php) this is affecting customers in the same range as yourself.

The SECTOOR blacklist is e.g. implemented by Hotmail, Live and Gmail. This results in other customers not being able to longer use the mail services of these companies.

[omissis details]

Therefore, we kindly, yet urgently ask you to disable the connection to the mentioned ports within 24 hours. Failure to comply and respond (confirm) to this warning, will result in a block of your involved IP address(es).

Thank you for your co-operation and understanding.

Kind regards,

[omissis]
Team Manager Abuse Prevention
LeaseWeb Global Services B.V.

PGP Public Key

clodo@clodo.it – Find it in common keyservers.
On pgp.mit.edu


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBE7vTfMBCADrsRfg06my/tJeGYFoNQwa8CZvy8GRvzQwFozlIntlDQtxIYEH
nW/imqpHyPKzs+28CS3eAEvPZvMj7yrQNubPwwjcS2IQq5NYOJXqXcyQiR6Nu6Le
10rnkvg5YPKaqsQn1KSTuFJA5/wUZtVrYF9O1fluE7xWQVGdfA7j14nAI56BmrqK
nWiBVQWY4nwcwGqv30cse1FOII0CQ6+1dzFbB53fgzUDGmORsFLuHX9kq2bQlday
FL5iP/Ge3OOt/Gz9Uh97mEmveKpnhw4Ic5Y61GY4CFHXAAdHz8AEYEGNwQ6qdi8F
peO/gOQRWzgJnI2EbzDGE8tf/y16S4BrhCSfABEBAAG0FkNsb2RvIDxjbG9kb0Bj
bG9kby5pdD6JATsEEwECACUFAk7vTfMCGyMFCQlmAYAGCwkIBwMCBBUCCAMDFgIB
Ah4BAheAAAoJEC/ixHrG0m4LE6AH/2dYL3Yvq1pZC+GdwgY8SLsI395iIDtBHGTn
c8pHn1ISJa306DBRqMZKGhFuG+FtDRCkWd+l3UKaLViPg/RxzS6HhnWth9W8Z+hh
iK5KYf85sygcSzXmhp/XBkWV9501GYdofCdkK8r+zsK0OM709pxLaZAFVmcDk4LV
vPMSGPFgGp/yC6fjv0R0MEfdYP1JH3XDBGBp7uBU2MJOu40s3Xty3QELWzBQw9eV
HPlIZepv46ELYrdzl9VOSNtZRF3k6117W/7vn1JPZDzyQWJe5SzITIifLhb9my7k
euPXSFx7Gbo0Y1oDSeNzysKkY8Efp3dWLp878LMT1CeEi1VZseK5AQ0ETu9N8wEI
AL3XzaWK5oK+bdzAFZcQ10xmonsrbHp/JZOXh8bvEktMxSqI37GcrfqG3BpIDwAJ
pNzuZsKeQBulItka1F41P7usYLI3midMKIkeIA0vBg08HoAFC+2YiUxFTFXdPp+s
ijfNcAAKOK1l1vU0vvpBwcULLB+e6EFnIoE1AQDKgimIlmEDFFny6AvjYEHy8Uay
NT9NBnDIPUBHWFGCkLN4aStUmkZcHTxZP9AJlpFAd02GPzMy8ptVDLtsiylGKmfE
eT373ULMd9JJoo2BlwFCqYrIhGHNL8VyW8CeB+9Szl9fYtr/pT6G5lgaiS7ooCnm
7TPY5YxtJNO8Pyh44jJB9lUAEQEAAYkBJQQYAQIADwUCTu9N8wIbDAUJCWYBgAAK
CRAv4sR6xtJuC/DcB/9LXL//hafXYIzWj95sLur5QRuNPNscekZL9DnJSon9d/9s
bsoZ7s8QKFJE4L1ZnUPIt8BM+mRdPfHgTJowYrejrP8yh+dNeZlLRRfRnbvmGH1M
NSm1huvVaD/vfkAaX4pyKD9kAnbTZfscbCrDwASqMbRk63YkzHT2Cw7qHKNhxl2w
OwdLp327ShQ0W7TTj/T7ZvOSDV/av/rS6a5I/EkyiwqwOLsYZE3RuSyygBW78GN9
liUs9AuUETB+lC8DqaXXho5tc+KEJURFGJ2ynTrRePvwiD355JIW5/dMCZS3bO63
mmt52baMDVOUqGGx7NL+zv2GgyEYTwuXftwqmfoh
=3G3H
-----END PGP PUBLIC KEY BLOCK-----

An alternative approach to so-called WebRTC leaks

Posted on Reddit here: http://redd.it/32d94q

Recently there were a lot of discussions about the WebRTC IP Leak. Almost all of them are talking about a “Security flaw” or treat it as a bug.

However, many articles about the WebRTC [leaks] talk about a solution: disable WebRTC in favorite browser.
Two questions:

  • Is it really a “Security flaw” that needs to be fixed in browsers? Look at browsers bug-reports to understand how many different opinions exist on this.
  • Why the browser can go outside the VPN tunnel? How many app/protocols can do the same things of the WebRTC leak? So, is disabling WebRTC a sufficient solution for those who use a VPN to avoid exposing their ISP IP address or traffic?

I will explain details of the issue. But first, if you are connected to a VPN service right now, try this:

ipdetection.zip (source available here )

or, under Unix try this (try also as root):

for s in `ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d'`; do curl --interface $s http://www.clodo.it/projects/whatismyip/; done

Is your real ISP IP leaked?

Details

When a user connects to OpenVPN, the main interface (ethernet, wifi etc) is still available (also to talk with the VPN server itself).
And another network interface is opened (tun/tap).
This is the scope of OpenVPN: create a tunnel.

As a plus, OpenVPN can be configured to push a directive from the server to their client: “redirect-gateway”.
This tells at client-side that ALL traffic needs to be redirected inside the tunnel by default.

Almost all VPN services use a specific option of that directive: “redirect-gateway def1”.
From OpenVPN manual

def1 — Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

Now, this means that the original 0.0.0.0/0 route are still active, but there are other routes created by OpenVPN that override the original based on precedence.
But 0.0.0.0/0 is a route assigned to the standard interface, while the new 0.0.0.0/1 and 128.0.0.0/1 are assigned to the TUN interface.

In every OS, when a connection/socket is opened, the program can choose a specific network interface that needs to be used.
This is not common, because most applications don’t need that and let the OS use the default network interface.

The program above do exactly this: bind to specific network interface to query an external what is my ip address service.
When binding to the standard interface, the overriding rules of OpenVPN are simply ignored, at least under Windows.

I think browsers do the same thing in WebRTC discovery.

Can a VPN service based on OpenVPN resolve the issue server-side, transparently to their users?

Yes.
Simply don’t use the def1 option in redirect-gateway directive.
Without def1, OpenVPN client removes totally the 0.0.0.0/0 route, and re-creates it at disconnection.

But I don’t recommend this approach: with def1, if the OpenVPN process is terminated, the overriding routes are automatically deleted or unused, and traffic continues to flow over the standard interface.
Without def1, if OpenVPN process is killed/terminated, the user remains without any route for his/her traffic.

For me, a good VPN service needs to use the def1 option, for the final consideration below.

Final consideration

WebRTC IP Leak is not a fault of browsers.

It is not a fault of OpenVPN (that is designed to be a Tunneling software, not an Always hide my traffic software).

It is a fault of users, because they trust the standard OpenVPN client for things out of its scope, or trust a badly-written VPN service client software.

Users need to use a VPN service that has a software addressing this kind of issue, or need to understand how to configure a firewall or a router.

*Disclaimer: *
I’m the author of the client software of a known VPN service. Anyway I don’t cite it in this reddit.