Per chi non sa cosa sia l’ IETF, probabilmente questo argomento e’ praticamente sconosciuto. Per chi c’era agli inizi, la parola IETF e’ , insieme ad RFC, un sinonimo di “la bibbia della rete”. Quando scrivete un sito web, quando scrivete un client di posta, quando si fa qualsiasi cosa, (a parte gli stardard, “de facto”, un altro nome della truffa ) si vanno a leggere ( o si dovrebbero leggere) gli RFC, dove si definisce bene che cosa debba e cosa non debba fare un client, un protocollo, un server.
Tutto questo , che era il motore della INternet (quando funzionava bene) , e’ il processo piu’ odiato dagli sviluppatori. L’avvento di linguaggi per scimmie sottopagate, come Java, Php e Python, nati con il preciso scopo di permettere a qualsiasi scimmia di scrivere software – e quindi di abbassare il reddito degli sviluppatori (1) – chiedere ad uno sviluppatore di web application, che lavora su http, di conoscere RFC1945 e RFC2616 e’ quasi una bestemmia. E vi sentirete dire che “il proxy deve essere trasparente” parlando di un reverse proxy o di un load balancer.
Oggi, IETF (http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force ) sta morendo.
Oh, non perche’ loro siano affamati o poco pagati. E’ perche’, essenzialmente, con le rivelazioni di snowden e’ venuto meno un contratto, una specie di gentlemen’s agreement , che diceva “se tutti rispettate le regole ci divertiremo un sacco” . Vi faccio un esempio concreto: ho comprato un Raspberry per farci un mailserver.
Voi direte… eh?
Si. Per girare un postfix ed un dovecot un RaspBerry e’ piu’ che sufficiente, e anche il demone noip2 viene compilato correttamente e gira senza problemi.
Perche’ l’ho fatto? PErche’ volevo provare cosa sarebbe successo oggi rompendo le regole.
In che modo ho rotto le regole? Violando un RFC.
Niente di grave: di per se’ ho solo settato
smtpd_tls_security_level = encrypt
nel server. Questo di per se’ e’ vietato dall’ RFC 2487 http://tools.ietf.org/html/rfc2487 , che poi e’ stato sostituito dall’ RFC 3207: esso recita:
A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet’s SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address. Quando feci questa cosa cinque anni fa, per dire, solo il 20-25% dei server riuscivano a parlare col mio. Il fatto che il mio server rispondesse con un errore prima di tutto, cosi’:
$ telnet uriel-fanelli.no-ip.org 25 Trying 87.175.195.234…
Connected to uriel-fanelli.no-ip.org.
Escape character is ‘^]’.
220 Welcome to ESMTP raspONE
EHLO keinpfusch.net
250-raspONE
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <[email protected]>
530 5.7.0 Must issue a STARTTLS command first
metteva un attimo in crisi i server impreparati. Sebbene essi supportassero TLS, era illegale (e teoricamente lo e’ ancora) che un server pretenda il TLS per ricevere mail sulla porta 25, che e’ quella usata pubblicamente per ricevere.
Ripeto: solo cinque anni fa, questo mi escludeva dal ricevere posta dall’ 80% dei server pubblici.
Adesso la situazione e’ cambiata. Ho eseguito prove da ogni dominio ove ho accesso per una email:
| Provider | Risultato |
| Gmail | OK |
| Yahoo | OK |
| Outlook | OK |
| T-Online.de | OK |
| Yandex Mail | OK |
| Mail.ru | OK |
| Vodafone.de | OK |
| Vodafone.com | OK |
| Ericsson.com | OK |
| Ericsson.se | OK |
| Ericsson.de | OK |
| Gmx.de | KO (ok-secondo tentativo) |
| Web.de | OK |
| Zoho | OK |
| ICloud | OK |
| Inbox.com | OK |
| OK | |
| Poste.it | OK |
tutti, e ripeto tutti, tranne GMX.de , hanno deliverato l’email al mio serverino. (2) Gmx ha prima fatto un tentativo ed e’ stato mandato via, al secondo tentativo ha accettato TLS. Non chiedetemi perche’.
Morale: se oggi vi fate un serverino di posta elettronica domestico usando no-ip org, oppure nel vostro server aziendale piazzate l’ OBBLIGO di usare TLS per criptare il traffico, non produrrete alcun disservizio.
Pero’, c’e’ un pero’: stiamo rompendo le regole. Un RFC mostra chiaramente che NON si deve fare questo, perche’ in caso a problemi verso un dominio, il certificato non sara’ corrispondente alla risoluzione inversa dell’ IP dell’host, per cui forzare TLS potrebbe significare che in caso di problemi sulla zona del DNS, chi dovrebbe essere avvisato per email non sara’ avvisato , visto che come il certificato non corrisponde al dominio.
In realta’ non e’ chissa’ quale crimine orribile: sto solo mostrando che tutti o quasi supportino TLS, e che quando viene offerto si limitano ad accettare, e se arriva il richiesto “530 5.7.0 Must issue a STARTTLS command first” obbediscono e fanno partire TLS.
Questo “obbediscono e fanno partire TLS”, cosa che potrebbero rifiutarsi di fare, e’ il punto. Il messaggio e’ previsto dall’ RFC, ma non e’ previsto che tutti DEBBANO rispettarlo. Invece, quei pochi che NON partono direttamente con TLS (gmx) appena viene annunciato, lo fanno poi quando arriva il messaggio.Messaggio che stando all’ RFC non deve MAI essere restituito da un server pubblico, e che quindi non dovrebbe essere accettabile.
Tuttavia, ormai praticamente TUTTI stanno ignorando questa regola, e se ne impippano bellamente, con tutti i rischi che questo implica (sebbene, nel mio caso io imponga solo la crittazione del flusso, e non la verifica della CA del certificato, o la sua validita’). Come mai? Quando e’ cambiato questo comportamento?
Il comportamento e’ cambiato insieme al progetto “Mail Made in Germany”, quando cioe’ alcuni provider (che gestiscono il 67% del flusso di email nazionale) hanno deciso di scambiarsi i certificati e di lavorare hop-to-hop solo in criptato, tra loro. (http://e-mail-made-in-germany.de/ ). Dopo aver pubblicizzato questa cosa ovunque, ogni CEO ha chiesto al servizio IT se la loro posta elettronica fosse altrettanto sicura, e i centralini di O2, Unitymedia e Vodafone in Germania sono stati intasati di chiamate che chiedevano loro se non fossero parte di questa alleanza, e se non fosse il caso di fare lo stesso.
Cosi’, per paura che l’onnipresente Stiftung Warentest ( http://test.de ) li bocciasse su questo punto dicendo “loro mandano email in chiaro”, tutti si sono adeguati. Ma la cosa non e’ solo tedesca: evidentemente tutti i grandi provider di posta avevano paura di essere sputtanati dicendo “gmail/outlook/yahoo manda in chiaro per permettere a NSA di spiarti”, e quindi anche loro si sono adeguati.
Del resto, la domanda e’ semplice: se NSA viola le regole che dicono “per intercettare Fanelli devi avere l’autorizzazione di un giudice”, perche’ io dovrei seguire le leggi scritte DAGLI AMERICANI?
Cosi’, la risposta e’ ovvia: se volete scrivere a [email protected], DOVETE per forza parlare TLS, cioe’ crittare la comunicazione, da server a server. Cosa che, nel 99% dei casi, fate gia’.
E lo fate gia’ perche’ qualcuno ha deciso che fosse il caso di sbattersene delle regole scritte dagli americani. Immaginate un dialogo cosi’:
- CEO: Dobbiamo essere sicuri che il nostro server comunichi SOLO in criptato. Gli americani spiano.
- IT: Ma non possiamo. Esistono due RFC che vietano di costringere il peer a parlare TLS.
- CEO: E chi ha scritto queste regole?
- IT: Gli americani dell’ IETF.
- CEO: Magguarda: gli stessi yankee che ci spiano ci vietano di criptare. Presto, prendi gli RFC e scrivici “per uso interno”.
- IT: Si , capo. Quanto lunghe devo fare le chiavi?
- CEO: piu’ lunghe.
- IT: bene.
questo e’ quello che si intende dire, quando sulle interviste si dice “gli USA hanno rotto Internet, inteso come contratto”. Adesso il punto e’ vedere quanto tempo resistera’, per esempio, HTTP. Quanto tempo passera’ prima che russi, o cinesi, o europei, sviluppino il LORO protocollo HTTP, in barba agli RFC? Quanto tempo passera’ prima che qualcuno costruisca il PROPRIO TCP, o il proprio IP in modo da piazzare un bel proxy tra la sua rete nazionale e il resto del mondo?(3)
Di per se’, ottenere sicurezza “brutal” in questo modo, su scala nazionale, e’ semplice.
Si prenda il protocollo, e si modifichi qualche parte essenziale. Per esempio, si decida di scrivere “al contrario” gli indirizzi nei campi del protocollo IP. Niente di che, da 11.22.33.44 il vostro indirizzo viene scritto 44.33.22.11 . A quel punto la rete continuera’ a funzionare come sempre, a patto che i DNS facciano lo stesso. Dovete scrivere la patch per i sistemi operativi che approvate nella vostra nazione, e poi forzare gli ISP ad usare il nuovo protocollo. Poi prendete il TCP, ed invertite che so l’ordine della porta, che so io da 80 diventa 08, 443 diventa 344, 25 diventa 52, e cosi’ via. (dovrete considerare sospetto ogni indirizzo contenga un 128, ok. Ma e’ un esempio: potete semplicemente aggiungere due bit ad ogni campo, e siete a posto ugualmente)
In questo modo, la vostra nazione piomba nell’isolamento, perche’ e’ impossibile parlare con voi dalla internet esterna. Cosi’ piazzerete dei bei proxy di scambio sul bordo, che prendono il vostro TCP/IP , leggono i pacchetti ed invertono i campi. Nemmeno troppo costoso sul piano computazionale. Fatto questo, siete ancora su internet, ma un eventuale attacco proveniente dall’esterno, fosse anche un enorme DDOS, colpira’ i proxy di scambio che stanno sul bordo. E non arrivera’ MAI all’obiettivo vero, sino a quando un proxy di scambio non lo lasciera’ passare: il pacchetto per girare su internet non puo’ corrispondere alla topologia interna, e viceversa.
Capite chiaramente quanti governi, oggi, siano tentati di fare questo.
Sinora nessuno ha voluto farlo, per la ragione che “internet” era uno strumento neutrale, che solo alcuni paesi tirannici filtravano. Ma oggi che e’ chiaro che la neutralita’ e’ violata praticamente da OGNI paese, gli RFC sono piu’ deboli che mai: perche’ mai si dovrebbero seguire le regole scritte dagli americani, sapendo che vengono scritte per garantire agli americani la forza di spiare gli altri?
Cosi’, IETF (e presto 3GPP fara’ la stessa fine) inizia a dover tollerare una semplice cosa, ovvero che sempre piu’ aziende se ne fottano bellamente degli RFC, ed iniziino a sviluppare protocolli propri. Un protocollo incompatibile con Internet, ed usato solo da una rete governativa, per dire, e’ una polizza vita: quel che c’e’ fuori non parla con quel che c’e’ dentro. Un problema di incompatibilita’ VOLUTO.
Anche senza arrivare a questi estremi, il problema e’ che “per quale motivo dovremmo seguire le regole?” e’ una domanda cui sempre meno tecnici sanno rispondere. Sinora la risposta era che INternet era uguale per tutti ed era neutra e neutrale, per cui conveniva cosi’ per parlare con tutti. Ma oggi che c’e’ una gran voglia di smetterla di parlare, i governi stanno iniziando a chiedere lo sviluppo di estensioni e modifiche capaci di rendere il TCP/IP nazionale (o governativo) incompatibile con l’esterno, in modo che neanche volendo possa avvenire un trasporto non voluto dai proxy di confine. Il pacchetto capace di entrare nella rete da proteggere non puo’ essere girato su internet, e viceversa.
E cosi’, con un colpo alla reputazione degli USA, si e’ inferto un colpo mortale ad IETF.
Tra pochi anni, ogni nazione avra’ il suo protocollo, con i suoi router di confine: questo e’ il problema. Oggi come oggi i TCP/IP “governativi” sono appannaggio di militari e pochi dipartimenti di alcune nazioni. Ma il numero di richieste di fattibilita’ e’ crescente.
Prima o poi, ed e’ questo il senso delle interviste che avete letto, il timore e’ che Internet si segmenti.
Uriel
(1) Quando gli sviluppatori hanno smesso di capire l’hardware e il sistema operativo, si e’ inventato Java. Gente che non sapeva niente di priorita’ , di filesystems, di allocazione della memoria, di jobscheduling, si e’ messa a programmare grazie a Java. Poi, visto che java arriva comunque con un compilatore, e questo e’ difficile, allora si e’ passati ad interpretare i programmi runtime, in modo che la scimmia non dovesse nemmeno capire come ottimizzare l’eseguibile che produceva. Chiedere ad una javascimmia di dirvi che genere di garbage collector usare o di quanta memoria abbia bisogno la JVM era troppo difficile, e le nuove scimmie cresciute su indorned hanno amato subito php e python, dove nessuno faceva mai domande difficili. Come a scuola, quando si chiedeva “ma adesso non e’ che all’esame chiedono TUTTO il programma , vero?”
(2) Non dovrei meravigliarmi se un’azienda tedesca segue gli RFC alla lettera. Lo so.
(3) Potete comunque piazzare un proxy ed un firewall, come hanno fatto i cinesi. Ma se usate lo stesso TCP di tutti gli altri su internet, il pacchetto ha qualche chance di uscire dalla vostra rete se e’ insospettabile. Il che vi espone alla steganografia. Al contrario, se sviluppate un TCP nazionale, il pacchetto non-puo-uscire dai confini, perche’ e’ considerato malformato fuori, e l’utente interno ha bisogno dei proxy del governo per usare il resto di internet. E’ una modifica semplicissima, basta swappare l’ordine bigendian/littleendian dell’ header TCP che indica la porta e il MSS, ed e’ relativamente semplice farlo anche a livello IP, invertendo l’ordine degli header origin/destination. Non ci vuole moltissimo, a produrre un TCP/IP nazionale: ridefinisci il protocollo e scrivi la patch per i sistemi operativi (costringendo tutti ad usare quelli governativi, btw).
