Into.the.Void.

5 years ago I forked Moritz’s tormap project, updated it a bit and wrote about it. Tormap kept running for years until some changes in googlemaps broke it, not all KMLs were loading as they should. I later on figured out that googlemaps didn’t like that some of the KML files were larger than 3Mb. I didn’t have much time to play with it until recently, so a few days ago I decided to make it work again. I used newer googlemaps v3 API calls and compressed KML (KMZ) files to make it work. Then @iainlearmonth and @nusenu_ suggested making even more changes…

Their first suggestion was to use onionoo instead of parsing consensus on my own and running geoip on it, onionoo already provides that in a nice json output. Their other suggestion was to switch tormap to use OpenStretMap instead of googlemaps mostly because googlemaps block some Tor exit nodes and the tiles didn’t appear on the map when visiting over Tor. Both of these issues are fixed now.

I used leaflet.js and a couple of plugins like leaflet-plugins (for KML parsing) and leaflet-color-markers for the switch to OpenStreetMap. I will admit that using googlemaps APIs was far more convenient for someone without any javascript knowledge like me.

Maybe in the next 5 years I will have time again to implement their other suggestion, creating maps of nodes based on custom searches for relay attributes. Unless someone else wants to implement that, feel free to fork it!

Filed by kargig at 11:56 under Internet,Linux,Networking,Privacy
Tags: googlemaps, javascript, map, Networking, OpenStretMap, OSM, Privacy, python, tor
No Comments | 8,943 views

2 months ago I wrote a blog post describing the really bad state of STARTTLS support of Greek email providers. Things have slightly gotten better since then.

Updates on STARTTLS support per provider
The following is current as of 2016/03/26 and are only the updates since the previous blog post.
FORTHNET: Supports TLS 1.2 (at least since 2016/02/03)
VODAFONE: Supports TLS 1.2 for vodafone.gr but NOT for vodafone.com.gr (at least since 2016/03/10)

Updates on Certificate status per provider (that have STARTTLS support)
FORTHNET: uses a valid certificate (a wildcard *.forthnet.gr)
VODAFONE: uses a valid certificate (a wildcard *.megamailservers.eu)
MAILBOX: uses a valid signed certificate (for spamexperts.eu) (at least since 2016/03/26)

No other changes have been observed.

These updates indicate that 3 out of 5 commercial Greek ISPs currently use STARTTLS on their mail servers, OTE/COSMOTE, Forthnet and Vodafone. Way better than 1 out 5 which was the case 2 months ago. That means that the only ones left behind are Wind and Cyta, Since HOL has merged with Vodafone.

P.S. Thanks fly to @stsimb for notifying me of Forthnet updates with a comment on my blog

Filed by kargig at 21:02 under Encryption,Greek,Internet,Linux,Networking,Privacy
Tags: certificate, email, Internet, ISP, Networking, Privacy, providers, security, startls, tls, verification
No Comments | 9,935 views

I started looking into the STARTTLS support of Greek email providers completely by accident when one email of mine wasn’t being delivered for some reason to a friend who has an email address at a traditional Greek ISP. I started looking into the delivery issues by running swaks against the email server of the ISP and I just couldn’t believe it that the ISP’s mail server response did not include STARTTLS support. That made me wonder about the rest of the ISPs, so I created a very simple script that takes domains, finds their MX addresses and performs very simple TLS lookups using openssl. Yeah I know that there are websites that track the STARTTLS support of mail servers, but they usually don’t save the previous results and you can’t grep and compare.

What I’ve looked into is how emails are sent between servers (SMTP), not if users can read emails from the mail servers (POP3/IMAP) using encrypted connections.

TL;DR
The situation is BAD, REALLY BAD. Only 1,5 (yes, this is one and a half) commercial ISPs supports STARTTLS. OTE/COSMOTE has “proper” STARTTLS support while Wind has STARTTLS support only for windtools.gr domain, but not for their wind.gr.

I couldn’t believe the situation was SO, SO BAD before looking at the results. It seems that I had a lot more faith in those providers than I should have. Yeah I was wrong once again.

wtf is STARTTLS?
(please don’t read the next sentence if you know what TLS is)
If you have no idea about TLS and STARTTLS, then consider STARTTLS a way for servers to communicate and exchange data in encrypted form instead of cleartext. If mail servers don’t support STARTTLS then other servers can’t send them emails in encrypted form and everyone between those 2 servers can read the emails. It’s the equivalent of “https://” for mail servers. (There, I said it…).

TLS support per provider
The following is current as of 2016/01/23

Commercial Providers
OTE/COSMOTE: Some servers support TLS version 1.0 and some others 1.2 (more on that later)
WIND: Supports TLS version 1.0 on windtools.gr but does NOT support TLS on wind.gr (different mail servers)
CYTA: Does NOT support TLS on their mail servers
FORTHNET: Does NOT support TLS on their mail servers
HOL: Does NOT support TLS on their mail servers
VODAFONE: Does NOT support TLS on their mail servers

non-Commercial Providers
GRNET: Supports TLS 1.2
SCH: Supports TLS 1.0
TEE: Does NOT support TLS on their mail servers
MIL: Supports TLS 1.0

Universities
AUTH: Supports TLS 1.2
NTUA: Some servers support TLS 1.0 and one supports TLS 1.2
UPATRAS: Supports TLS 1.0

Free Providers
IN: Does NOT support TLS on their mail servers
FREEMAIL: Does NOT support TLS on their mail servers
MAILBOX: Supports TLS 1.2

Radical Providers
ESPIV: Supports TLS 1.2

Certificate status per provider (that have STARTTLS support)
OTE/COSMOTE: *.otenet.gr mail servers, which are the ones that support TLS 1.0, use a certificate that is valid for mailgate.otenet.gr, *.ote.gr mail servers have their own certificates, but all mail*.dt-one.com mail servers, which are the ones that use TLS 1.2, use the same self-signed certificate.
WIND: mx2.windtools.gr uses a valid certificate
GRNET: uses a valid certificate
SCH: uses a self-signed certificate (which has expired 5 years ago) signed by their own CA (which has expired 4 years ago)
MIL: uses a self-signed certificate (which has expired 1 year ago) signed by their own CA
AUTH: uses a certificate signed by their own CA called HARICA, whose certificate is now included in modern OSes, so I will consider this a valid certificate.
NTUA: all mail servers use a certificate that is valid for mail.ntua.gr
UPATRAS: uses a valid certificate
MAILBOX: uses a self-signed certificate (by plesk)
ESPIV: uses a valid certificate (a wildcard *.espiv.net)

Why does it matter
It makes a huge difference for users’ privacy. If a mail server does not support STARTTLS then anyone with the ability to look into packets traveling on the net from a source mail server to the destination mail server can read the emails in pure plaintext, as you read them on your mail client. Support of STARTTLS for a mail server forces an adversary that previously just passively monitored traffic to have to start a MITM (Man in the middle) attack in order to read those same emails. This converts the adversary from a passive to an active attacker. And this is both expensive and dangerous for the adversary, it can get caught in the act.

Security and privacy-minded people might start bashing me on my next proposal, but considering the current situation I think it’s OK for most of the users of those providers that don’t support TLS at all.
Dear providers, please install a certificate, even a self-signed one, and add support for STARTTLS on your mail servers today.

Even a self-signed certificate improves this situation. And it costs absolutely nothing. There’s really no excuse to not even have a self-signed certificate for your email server.

Self-signed vs CA-Signed
Truth is that it 99.9999% of email servers on the Internet do not verify the remote end’s certificate upon communication. That means that it makes absolutely no difference in most cases whether the certificate is CA-signed or self-signed. Most modern email servers support fingerprint verification for remote servers’ certificates but this can’t obviously scale on the Internet. If a user fears that some entity could MITM their email provider just to read their email, they already have bigger problems and certificate verification would not be able to help them a lot anyway. They either need to protect the contents of their email (gpg?) or start using alternate means of messaging/communication (pond?)

script
The script I used is on github: gr-mx. Feel free to make changes and send pull requests.
I plan to run the script once a week just to keep an archive of the results and be able to track and compare. Let’s see if something changes…

Various weirdness
* windtools.gr has 2 MX records, mx1.windtools.gr and mx2.windtools.gr. mx1.windtools.gr has been unreachable since I started running the script on 2016/01/08.
* mail{5,6,7,8}.dt-one.com mailservers used by OTE/COSMOTE did not have the self-signed certificate on 2016/01/08 while mail{1,2,3,4}.dt-one.com had it. The certificate was added at some point between 2016/01/11 and 2016/01/17

Filed by kargig at 15:55 under Encryption,Greek,Internet,Linux,Networking,Privacy
Tags: certificate, email, Internet, ISP, Networking, Privacy, providers, security, startls, tls, verification
3 Comments | 19,206 views

Οι περισσότεροι χρήστες του Ελληνικού Internet αν ρωτηθούν για το κατά πόσο υπάρχει, κρατική ή μη, λογοκρισία σήμερα μάλλον θα απαντήσουν αρνητικά. Η λογοκρισία τη σύγχρονη εποχή δυστυχώς είναι πολύ πιο ύπουλη από ότι στο παρελθόν. Πολλές φορές δεν ξέρουμε καν ποιος είναι ο λογοκριτής και γιατί κάτι είναι απαγορευμένο. Η λογοκρισία, μέρος της οποίας είναι οι κανόνες απαγόρευσης επίσκεψης ή χρήσης συγκεκριμένων sites, ζει και βασιλεύει σήμερα στην Ελλάδα. Όμως, λόγω της ανοργάνωτης δομής του κράτους του ίδιου και η λογοκρισία είναι το ίδιο ανοργάνωτη: όποιος μπορεί λογοκρίνει ό,τι μπορεί αρπάζοντας την ευκαιρία που βρίσκει μπροστά του.

Το Internet στην Ελλάδα δεν είναι κρατικό, ούτε υπάρχει ένας φορέας που να ελέγχει το που συνδέονται οι χρήστες, οπότε η επιβολή των όποιων περιορισμών πρέπει να γίνεται αποκλειστικά από τους παρόχους Internet, πχ Cosmote,Forthnet,Vodafone,κτλ. Οι πάροχοι παίζουν τεράστιο ρόλο στην επιβολή λογοκρισίας, είναι αυτοί που καλούνται από τα δικαστήρια να υπερασπιστούν την μη-επιβολή κανόνων αλλά και αυτοί που πρέπει να αμφισβητήσουν ή να ερμηνεύσουν τα νομικά κείμενα που τους στέλνουν διάφορες αρχές/οργανισμοί/κτλ για να εφαρμόσουν. Μέχρι ένα σημείο είχαν/έχουν και οικονομικό κίνητρο να μην εφαρμόζουν μεθόδους λογοκρισίας γιατί η διαχείριση και λειτουργία μηχανημάτων και φίλτρων σε αυτά, που σκοπό έχουν μόνο την λογοκρισία, είναι για τους παρόχους οικονομική επιβάρυνση. Επίσης αν δεν υπάρχει φορέας που να επιβάλει την τήρηση των ίδιων κανόνων λογοκρισίας από όλους τους παρόχους, τότε ο πιο “ελαστικός” πάροχος θα αρχίσει να παίρνει τους χρήστες που φεύγουν από τους υπόλοιπους παρόχους. Όσο πιο “μεγάλος” είναι ένας πάροχος τόσο περισσότερο υποχρεώνεται να είναι τυπικός στις λογοκριτικές του υποχρεώσεις. Από την στιγμή όμως που οι πάροχοι υποχρεωθούν να βρουν (τεχνικούς) τρόπους λογοκρισίας των χρηστών, τότε το οικονομικό βάρος το έχουν ήδη επωμιστεί και άρα δεν έχουν ισχυρούς λόγους να συνεχίσουν να υπερασπίζονται τους χρήστες με το ίδιο πάθος όπως έκαναν παλιά. Και αυτό ακριβώς συμβαίνει σήμερα πλέον.

Ποιοι έχουν επιβάλει λογοκρισία μέχρι σήμερα στο Ελληνικό Internet όμως και πως; Τα παρακάτω σίγουρα δεν είναι η πλήρης εικόνα του τι έχει συμβεί τα τελευταία χρόνια αλλά έχω πιάσει μερικά κομμάτια που τα θεωρώ ενδεικτικά της αρρωστημένης κατάστασης που επικρατεί.

Τα δικαστήρια
Καταρχήν τα Ελληνικά δικαστήρια με την απόφαση 4658/2012 δημιούργησαν τις πρώτες 2 “τρύπες” στο Ελληνικό Internet. Οι πάροχοι σύμφωνα με την απόφαση υποχρεώθηκαν να κόψουν από τους routers τους την πρόσβαση προς τις IPs 67.159.26.126 και 217.23.143.152. Ακόμα και σήμερα, οι 2 συγκεκριμένες IPs δεν είναι προσβάσιμες (εμφανίζονται * * * = δεν φεύγουν πακέτα μετά τους routers της Cosmote):

$ traceroute 217.23.143.152
traceroute to 217.23.143.152 (217.23.143.152), 30 hops max, 60 byte packets
*snipped*
 5  athe-crsa-thes-crsa-4.backbone.otenet.net (79.128.224.141)  56.557 ms  56.559 ms  60.387 ms
 6  athe6513k1-athe-crsa.backbone.otenet.net (79.128.227.74)  56.533 ms  37.518 ms  20.960 ms
 7  athe384z-ge00.otenet.net (62.103.4.192)  22.777 ms  27.164 ms  28.518 ms
 8  * * *
 9  * * *

ενώ για μια “διπλανή” IP η πρόσβαση είναι ελεύθερη, φεύγουν πακέτα πέρα από την Cosmote:

$ traceroute 217.23.143.151
traceroute to 217.23.143.151 (217.23.143.151), 30 hops max, 60 byte packets
*snipped*
 4  thes-crsb-thes7609b-1.backbone.otenet.net (79.128.228.133)  30.735 ms  34.759 ms  35.376 ms
 5  62.75.8.137 (62.75.8.137)  77.951 ms  78.097 ms  78.749 ms
 6  62.75.8.34 (62.75.8.34)  92.460 ms 62.75.8.22 (62.75.8.22)  82.512 ms 62.75.8.54 (62.75.8.54)  82.938 ms
 7  mil-cr01-te6-2.lnd.stream-internet.net (195.66.224.218)  80.490 ms  82.161 ms  78.793 ms
 8  anc-cr01-be5.204.ff.stream-internet.net (195.34.53.225)  99.192 ms  78.622 ms  76.786 ms
 9  bor-cr03-be1.78.spb.stream-internet.net (212.188.29.94)  111.910 ms  111.919 ms  115.771 ms
10  m9-cr04-be2.78.msk.stream-internet.net (212.188.28.114)  125.109 ms  118.581 ms 118.586 ms
...

Δεν υπάρχει χρονικό όριο το πότε θα αρθεί αυτός ο περιορισμός. Αν δεν αποφασίσει κάποιο άλλο δικαστήριο για την άρση του, θα μείνει για πάντα. Και αυτή τη στιγμή δεν λειτουργεί κάποιο “παράνομο” website στους 2 servers αυτούς, ό,τι και να τρέχει εκεί πλέον οι Έλληνες χρήστες δεν μπορούν να το δουν.

Η ΕΕΕΠ
Ο μεγαλύτερος μέχρι σήμερα λογοκριτής στην Ελλάδα είναι όμως η ΕΕΕΠ. Ο φορέας που κατάφερε και έγινε ανεξάρτητη αρχή και σιγά σιγά απέκτησε το δικαίωμα να κόβει όποιο site δεν έχει άδεια στοιχηματζίδικου στην Ελλάδα. Το κατά πόσο αυτό έχει νόημα είναι μια άλλη, τεράστια, κουβέντα, αλλά σήμερα η ΕΕΕΠ έχει την εξουσία να υποχρεώνει τους παρόχους να κόβουν 438 διαφορετικά sites στοιχηματικού ενδιαφέροντος που αναφέρονται στην blacklist της. Το γεγονός πως δεν αναφέρουν όλοι οι πάροχοι το πως κάνουν αυτό το κόψιμο (τεχνικά) και το γιατί δεν έκοβαν (ή δεν κόβουν ακόμα) όλοι οι πάροχοι όλα τα sites της blacklist έχει μελετηθεί στην έρευνα EEEP and Greek Internet censorship (δυστυχώς ακόμα εκκρεμεί η Ελληνική μετάφραση καθώς και μια επικαιροποίηση της έρευνας).

Παράδειγμα λογοκρισίας (DNS manipulation) ενός site μέσα από την blacklist της ΕΕΕΠ από την Cosmote (195.170.2.1 είναι ένας DNS server της Cosmote):

$ dig www.777.com @195.170.2.1 +short
83.235.64.20
$ dig -x 83.235.64.20 +short
eeep.otenet.gr.

Οι δύο παραπάνω εντολές αυτές δείχνουν πως η Cosmote έχει γυρίσει τις DNS απαντήσεις για το site www.777.com σε ένα δικό της server (83.235.64.20). Περισσότερα γι’ αυτό παρακάτω.

Η υπόθεση με τα φάρμακα
Για να μπορέσουν οι πάροχοι να υπακούσουν στις προσταγές της ΕΕΕΠ εγκατέστησαν συστήματα περιορισμού της πρόσβασης των χρηστών, πχ DNS manipulation, DPI (Deep Packet Inspection), κτλ. Τι γίνεται όταν υπάρχουν ήδη τέτοια συστήματα ενεργά; Αρχίζει ο καθένας και τα χρησιμοποιεί όπως τον βολεύει. Ωραιότατο παράδειγμα το http://αγοραβιαγκρα.com (http://xn--mxaaaaded0cl8bwg.com) το οποίο δεν άρεσε στο Πανελλήνιο Φαρμακευτικό Σύλλογο και έτσι έστειλαν επιστολή προς Υπουργείο Υγείας, Διεύθυνση Ηλεκτρονικού Εγκλήματος (ΔΗΕ), ΕΕΤΤ λέγοντας πόσο δεν τους αρέσει που υπάρχει ένα ηλεκτρονικό φαρμακείο και πως πρέπει να παρθούν τα νόμιμα μέτρα. Έπειτα οι ISPs φαίνεται πως έκοψαν την πρόσβαση στο site αυτό χωρίς να υπάρχει απόφαση δικαστηρίου (τουλάχιστον κάποια που να έχει ανακοινωθεί)!!! Φήμες φέρουν την ΔΗΕ να επικοινώνησε με τους ISPs και να τους ζήτησε να κόψουν το συγκεκριμένο site. Με ποια αρμοδιότητα βέβαια αποφασίζει ένα τμήμα της αστυνομίας ποιος θα βλέπει τι στο Internet είναι μια πάρα πολύ καλή ερώτηση για τους νομικούς. Αν κάποιος έχει κάποια απόφαση δικαστηρίου, πχ ασφαλιστικά μέτρα που κέρδισε ο ΠΦΣ για την συγκεκριμένη υπόθεση ας το στείλει στα comments.

Πως απέκλεισε η Cosmote το αγοραβιαγκρα.com; με τον ίδιο τρόπο που αποκλείει και τα sites της blacklist της ΕΕΕΠ, αλλάζοντας τις DNS απαντήσεις:

$ dig xn--mxaaaaded0cl8bwg.com +short @195.170.2.1
83.235.64.19
$ dig -x 83.235.64.19 +short @195.170.2.1
abuse.otenet.gr.

ενώ η σωστή απάντηση είναι:

$ dig xn--mxaaaaded0cl8bwg.com +short @149.20.64.20
82.211.30.73

να και το screenshot από αυτό που αντικρίζει κανείς όταν επισκέπτεται το αγοραβιαγκρα.com από σύνδεση Cosmote:

Η εξήγηση που αναγράφει η σελίδα είναι για γέλια και για κλάματα. Αφορά διακοπή πρόσβασης σε site που “προσομοιάζει υπηρεσία του ομίλου ΟΤΕ”. Ο ΟΤΕ δεν πουλάει φάρμακα από όσο ξέρω. Τσαπατσουλιά φουλ. Καμία αναφορά στο ποιος επέβαλε την απαγόρευση και γιατί. Δεν μπορείς να το δεις το site…γιατί έτσι.

Το αν είναι παράνομο να αγοράζει κανείς φάρμακα από ένα website είναι τελείως ασύνδετο με το ποιος αποφασίζει για την απαγόρευση της πρόσβασης στο website αυτό και την σωστή ενημέρωση των χρηστών για τους λόγους απαγόρευσης πρόσβασης. Δεν μπορεί αυτές οι αποφάσεις να παίρνονται ούτε από κάποιον σύλλογο ούτε και από την αστυνομία. Θα έπρεπε να υπάρχει τουλάχιστον κάποιο link προς την απόφαση του δικαστηρίου (αν υπάρχει) που να εξηγεί το σκεπτικό της απαγόρευσης της πρόσβασης.

Η πιο κρίσιμες ερωτήσεις για μένα όμως είναι:
α)Πόσα άλλα sites σαν το αγοραβιαγκρα.com άραγε ανακατευθύνει η Cosmote, αλλά και ο κάθε άλλος πάροχος, σε σελίδα που απλά λέει πως απαγορεύεται η πρόσβαση;
β) Ποιος ακριβώς διέταξε τις απαγορεύσεις αυτές;

ΕΕΕΠ++
Τι άλλο μπορεί να κάνει η ΕΕΕΠ για να βελτιώσει την εξουσιαστική της θέση; να ξέρει πόσοι (και ποιοι) χρήστες προσπαθούν να επισκεφτούν τα sites που διατηρεί στην blacklist της. Βέβαια, το να υποχρεώσει τους παρόχους να δώσουν στοιχεία από τα DNS queries που υποχρεώνονται να χειραγωγούν είναι αρκετά επίπονη τεχνικά εργασία, αλλά υπάρχει απλούστερη λύση. Κάθε πάροχος να κάνει το DNS manipulation των απαντήσεών που δίνει προς ένα δικό του server, η Cosmote για παράδειγμα το κάνει προς το server με IP 83.235.64.20, και έπειτα εκεί σε HTTP επίπεδο να ανακατευθύνει τους χρήστες προς τον webserver της ΕΕΕΠ, σε μια συγκεκριμένη σελίδα. Έτσι η ΕΕΕΠ μπορεί να εξάγει με άνεση ό,τι στατιστικά θέλει από την επισκεψιμότητα αυτής της σελίδας.

Επίσκεψη από σύνδεση Cosmote προς www.777.com και αυτόματη ανακατεύθυνση προς ΕΕΕΠ-> https://www.gamingcommission.gov.gr/index.php/forbidden-access-black-list/:

$ curl -I http://www.777.com
HTTP/1.1 302 Found
Date: Tue, 05 Jan 2016 13:15:29 GMT
Server: Apache
Location: https://www.gamingcommission.gov.gr/index.php/forbidden-access-black-list/
Connection: close
Content-Type: text/html; charset=iso-8859-1

Με αυτό τον τρόπο η ΕΕΕΠ πλέον γνωρίζει ποια IP χρήστη και ποια ώρα προσπάθησε να επισκεφτεί ένα “απαγορευμένο” site. Η επόμενη κίνηση λογικά θα είναι να διατάζει και άρση απορρήτου για όσους προσπαθούν να επισκεφτούν συχνά τέτοια sites. Υπάρχει ένα τεράστιο θέμα όμως εδώ, ο νόμος δεν υποχρεώνει τους παρόχους να ανακατευθύνουν τους πελάτες στους στο site της ΕΕΕΠ, ούτε να δίνουν στατιστικά στοιχεία για το πόσες επισκέψεις κάνει ο καθένας, παρόλα αυτά η ΕΕΕΠ το ζήτησε και οι πάροχοι συμμορφώθηκαν. Το γιατί είναι εντελώς ανεξήγητο.

Το ζοφερό μέλλον
Επειδή τέτοια ζητήματα δεν γίνεται φυσικά να έχουν καμιά θετική εξέλιξη στο πέρασμα του χρόνου, παρά μόνο αρνητική, να τι φέρνει ο νέος νόμος για τη συλλογική διαχείριση δικαιωμάτων πνευματικής ιδιοκτησίας όπως έχει αναρτηθεί σε δημόσια διαβούλευση αυτή τη στιγμή στο Internet. Στο άρθρο 69 παράγραφος 8 μας φέρνει την “Επιτροπή για τη γνωστοποίηση διαδικτυακής προσβολής δικαιωμάτων πνευματικής ιδιοκτησίας και συγγενικών δικαιωμάτων” όπου η πενταμελής αυτή επιτροπή θα έχει 2 μέλη του ΟΠΙ (Οργανισμός Πνευματικής Ιδιοκτησίας), ένα της ΕΕΤΤ (Εθνική Επιτροπή Τηλεπικοινωνιών & Ταχυδρομείων) και 2 δικαστές. Να βάλουμε τους λύκους να φυλάνε τα πρόβατα δηλαδή. Αυτή η επιτροπή ενημερώνει παρόχους Internet και παρόχους υπηρεσιών φιλοξενίας για την παραβίαση πνευματικών δικαιωμάτων από χρήστες τους και τους καλεί να απομακρύνουν το περιεχόμενο. Αν δεν συμμορφωθούν επιβάλει πρόστιμα. Τα παραπάνω τα φέρνει το ίδιο κόμμα που το 2010 είχε βγάλει ανακοίνωση υποστήριξης του gamato.info αλλά φυσικά το 2015 αποφάσισαν να τσακώσουν τους διαχειριστές του gamatotv.com.

Future Blacklists
Ε το μόνο που μας μένει είναι να αποκτήσουμε μια επιτροπή, ανεξάρτητη αρχή, ή όπως αλλιώς θα ονομάζεται που να αποφασίζει πως για λόγους ηθικής τάξης θα πρέπει να κόβονται websites. Ή ακόμα καλύτερα να κόβονται sites γιατί προωθούν την “τρομοκρατία”. Για το καλό μας πάντα. Αν ήταν λίγο πιο γάτες εκεί στο Υπουργείο Οικονομικών θα έβγαζαν blacklist ώστε όσα μαγαζιά έχουν eshop και δεν πληρώνουν ΦΠΑ και φόρους να τους κόβουν από το Internet. Πριν 2-3 χρόνια συνέλαβαν το γέροντα Παστίτσιο για βλασφημία, δεν θα μου κάνει καμία εντύπωση να δούμε και καμιά blacklist από την Εκκλησία της Ελλάδος για την προστασία των πιστών…

Τα παραπάνω φαίνονται αστεία, όσο αστείο ήταν παλιά πως θα υπήρχε κάποια επιτροπή που θα αποφάσιζε που επιτρέπεται να χάνει κάποιος τα λεφτά του.

Η αδράνεια
Το πιο στενάχωρο για μένα είναι η πλήρης αδράνεια των χρηστών να εναντιωθούν σε όλα τα παραπάνω. Δεν υπάρχει καμία οργανωμένη αντίδραση. Ούτε καν κείμενα σχολιασμού.
Το HELLUG έχει πλέον ελάχιστα ενεργά μέλη και δεν είναι πλέον σε θέση να εκφράσει απόψεις και να στηρίξει δράσεις όπως το έκανε στο παρελθόν με το digitalrights.gr
Η ΕΕΧΙ επίσης δεν εκφράζει δημόσιο λόγο (δεν ξέρω αν έχει καν μέλη πλέον).
Το adslgr δεν βλέπω να μπορεί να οργανώσει κάτι, το να γράφουν μερικοί κάποια εκνευρισμένα posts σε ένα forum δεν αρκεί ούτε και αλλάζει κάτι.
To DLN είναι σχεδόν νεκρό και πλέον δεν έχει τις δυνάμεις να σχολιάζει καν τα όσα συμβαίνουν. Η mailing list λειτουργεί αλλά έχει ελάχιστη κίνηση. Παρόλα αυτά είναι μάλλον το μοναδικό σημείο ενημέρωσης για τέτοια ζητήματα.
To Collision Resistance δεν κατάφερε καν να ξεκινήσει.

Υπάρχει μια γενικότερη παραίτηση του κόσμου γύρω από τα θέματα αυτά, ίσως φυσικό αποτέλεσμα των όσων συμβαίνουν γενικότερα στην Ελλάδα τα τελευταία χρόνια.

“Ε δεν πειράζει μωρέ, τι χειρότερο μπορεί να συμβεί;” Τα καλύτερα έρχονται!

* Bonus *
Η αποφυγή
Ο πιο εύκολος τρόπος να αποφύγει κανείς κάθε περιορισμό που έχει τεθεί μέχρι σήμερα είναι να χρησιμοποιήσει κάτι σαν το Tor. Δεν χρειάζεται ούτε να αλλάξει DNS servers, ούτε να αγοράσει VPN. Κατεβάζει τον Tor Browser και συνεχίζει ό,τι έκανε παλιά σαν να μην συμβαίνει τίποτα. Ο δρόμος αυτός όμως είναι και επικίνδυνος, αν αφήσουμε την προσβασιμότητα στο Internet στο πόσο καλά λειτουργούν 1-2 εργαλεία δεν θα αργήσει να έρθει η ώρα που ακόμα και αυτά δεν θα αρκούν. Ο σωστός δρόμος είναι να οργανωθούν οι χρήστες σε ομάδες, κοινότητες και οργανώσεις και να εκφράσουν μαζικά τις αντιρρήσεις και αντιδράσεις τους στα παραπάνω. Όχι με tweets και με posts στο Facebook.

Filed by kargig at 15:03 under General,Greek,Internet,Networking,Privacy
Tags: dns, dpi, Greek, Internet, Privacy, tor, απαγόρευση, αστυνομία, ΔΗΕ, δικαστήριο, ΕΕΕΠ, ΕΕΤΤ, λογοκρισία, ΠΦΣ
6 Comments | 17,781 views

Inspired from another project called “Anonymous Wikipedia edits from the Norwegian parliament and government offices” I decided to create something similar for the Hellenic Parliament.

I downloaded the XML dumps (elwiki-20140702-pages-meta-history.xml.7z) for the elwiki from http://dumps.wikimedia.org/elwiki/20140702/. The compressed file is less than 600Mb but uncompressing it leads to a 73Gb XML which contains the full history of edits. Then I modified a parser I found on this blog to extract the data I wanted: Page Title, Timestamp and IP.

Then it was easy to create a list that contains all the edits that have been created by Hellenic Parliament IPs (195.251.32.0/22) throughout the History of Hellenic Wikipedia:
The list https://gist.github.com/kargig/d2cc8e3452dbde774f1c.

Interesting edits

1. Former Prime Minister “Κωνσταντίνος Σημίτης”
   An IP from inside the Hellenic Parliament tried to remove the following text at least 3 times in 17-18/02/2014. This is a link to the first edit: Diff 1.

   Για την περίοδο 1996-2001 ξοδεύτηκαν 5,2 τρις δρχ σε εξοπλισμούς. Οι δαπάνες του Β` ΕΜΠΑΕ (2001-2006) υπολογίζεται πως έφτασαν τα 6 με 7 τρις δρχ.[http://www.enet.gr/online/online_hprint?q=%E5%EE%EF%F0%EB%E9%F3%EC%EF%DF&a=&id=71538796 ”To κόστος των εξοπλισμών”], εφημερίδα ”Ελευθεροτυπία”, δημοσίευση [[1 Αυγούστου]] [[2001]].Έπειτα απο τη σύλληψη και ενοχή του Γ.Καντά,υπάρχουν υπόνοιες για την εμπλοκή του στο σκάνδαλο με μίζες από Γερμανικές εταιρίες στα εξοπλιστικά,κάτι το οποίο διερευνάται απο την Εισαγγελία της Βρέμης.

2. Former MP “Δημήτρης Κωνσταντάρας”
   Someone modified his biography twice. Diff Links: Diff 1 Diff 2.
3. Former football player “Δημήτρης Σαραβάκος”
   In the following edit someone updated this player’s bio adding that he ‘currently plays in porn films’. Diff link. The same editor seems to have removed that reference later, diff link.
4. Former MP “Θεόδωρος Ρουσόπουλος”
   Someone wanted to update this MP’s bio and remove some reference of a scandal. Diff link.
5. The movie “Ραντεβού με μια άγνωστη”
   Claiming that the nude scenes are probably not from the actor named “Έλενα Ναθαναήλ”. Diff link.
6. The soap opera “Χίλιες και Μία Νύχτες (σειρά)”
   Someone created the first version of the article on this soap opera. Diff Link.
7. Politician “Γιάννης Λαγουδάκος”
   Someone edited his bio so it seemed that he would run for MP with the political party called “Ανεξάρτητοι Έλληνες”. Diff Link
8. University professor “Γεώργιος Γαρδίκας”
   Someone edited his profile and added a link for amateur football team “Αγιαξ Αιγάλεω”. Diff Link.
9. Politician “Λευτέρης Αυγενάκης”
   Someone wanted to fix his bio and upload a file, so he/she added a link from the local computer “C:\Documents and Settings\user2\Local Settings\Temp\ΑΥΓΕΝΑΚΗΣ”. Diff link.
10. MP “Κώστας Μαρκόπουλος”
    Someone wanted to fix his bio regarding his return to the “Νέα Δημοκρατία” political party. Diff Link.
11. (Golden Dawn) MP “Νίκος Μιχαλολιάκος”
    Someone was trying to “fix” his bio removing some accusations. Diff Link.
12. (Golden Dawn) MP “Ηλίας Κασιδιάρης”
    Someone was trying to fix his bio and remove various accusations and incidents. Diff Link 1, Diff Link 2, Diff Link 3.

Who’s done the edits ?
The IP range of the Hellenic Parliament is not only used by MPs but from people working in the parliament as well. Don’t rush to any conclusions…
Oh, and the IP 195.251.32.48 is probably a proxy inside the Parliament.

Threat Model
Not that it matters a lot for MPs and politicians in general, but it’s quite interesting that if someone “anonymously” edits a wikipedia article, wikimedia stores the IP of the editor and provides it to anyone that wants to download the wiki archives. If the IP range is known, or someone has the legal authority within a country to force an ISP to reveal the owner of an IP, it is quite easy to spot the actual person behind an “anonymous” edit. But if someone creates an account to edit wikipedia articles, wikimedia does not publish the IPs of its users, the account database is private. To get an IP of a user, one would need to take wikimedia to courts to force them to reveal that account’s IP address. Since every wikipedia article edit history is available for anyone to download, one is actually “more anonymous to the public” if he/she logs in or creates a (new) account every time before editing an article, than editing the same article without an account. Unless someone is afraid that wikimedia will leak/disclose their account’s IPs.
So depending on their threat model, people can choose whether they want to create (new) account(s) before editing an article or not 🙂

Similar Projects

Parliament WikiEdits

congress-edits

Riksdagen redigerar

Stortinget redigerer

AussieParl WikiEdits

anon

Bonus
Anonymous edit from “Synaspismos Political Party” (ΣΥΡΙΖΑ) address range for “Δημοκρατική Αριστερά” political party article, changing it’s youth party blog link to the PASOK youth party blog link. Diff Link

Filed by kargig at 15:10 under General,Greek,Internet,Privacy
Tags: anonymity, hellenic parliament, Privacy, wikimedia, wikipedia
No Comments | 19,506 views

More and more privacy experts are nowdays calling people to move away from the email service provider giants (gmail, yahoo!, microsoft, etc) and are urging people to set up their own email services, to “decentralize”. This brings up many many other issues though, and one of which is that if only a small group people use a certain email server, even if they use TLS, it’s relatively easy for someone passively monitoring (email) traffic to correlate who (from some server) is communicating with whom (from another server). Even if the connection and the content is protected by TLS and GPG respectively, some people might feel uncomfortable if a third party knew that they are actually communicating (well these people better not use email, but let’s not get carried away).

This post is about sending SMTP traffic between two servers on the Internet over Tor, that is without someone being able to easily see who is sending what to whom. IMHO, it can be helpful in some situations to certain groups of people.

There are numerous posts on the Internet about how you can Torify all the SMTP connections of a postfix server, the problem with this approach is that most exit nodes are blacklisted by RBLs so it’s very probable that the emails sent will either not reach their target or will get marked as spam. Another approach is to create hidden services and make users send emails to each other at their hidden service domains, eg username@a2i4gzo2bmv9as3avx.onion. This is quite uncomfortable for users and it can never get adopted.

There is yet another approach though, the communication could happen over Tor hidden services that real domains are mapped to.

HOWTO
Both sides need to run a Tor client:
aptitude install tor torsocks

The setup is the following, the postmaster on the receiving side sets up a Tor Hidden Service for their SMTP service (receiver). This is easily done in his server (server-A) with the following line in the torrc:
HiddenServicePort 25 25. Let’s call this HiddenService-A (abcdefghijklmn12.onion). He then needs to notify other postmasters of this hidden service.

The postmaster on the sending side (server-B) needs to create 2 things, a torified SMTP service (sender) for postfix and a transport map that will redirect emails sent to domains of server-A to HiddenService-A.

Steps needed to be executed on server-B:
1. Create /usr/lib/postfix/smtp_tor with the following content:

#!/bin/sh

torsocks /usr/lib/postfix/smtp $@

2. Make it executable
chmod +x /usr/lib/postfix/smtp_tor

3. Edit /etc/postfix/master.cf and add a new service entry
smtptor unix - - - - - smtp_tor
For Debian Stretch and/or for postfix 2.11+ this should be:

smtptor      unix  -       -       -       -       -       smtp_tor
  -o smtp_dns_support_level=disabled

4. If you don’t already have a transport map file, create /etc/postfix/transport with content (otherwise just add the following to your transport maps file):

domain-a.net        smtptor:[abcdefghijklmn12.onion]
domain-b.com        smtptor:[bbbcccdddeeeadas.onion]

5. if you don’t already have a transport map file edit /etc/postfix/main.cf and add the following:
transport_maps = hash:/etc/postfix/transport

6. run the following:
postmap /etc/postfix/transport && service postfix reload

7. If you’re running torsocks version 2 you need to set AllowInbound 1 in /etc/tor/torsocks.conf. If you’re using torsocks version 1,you shouldn’t, no changes are necessary.

Conclusion
Well that’s about it, now every email sent from a user of server-B to username@domain-a.net will actually get sent over Tor to server-A on its HiddenService. Since HiddenServices are usually mapped on 127.0.0.1, it will bypass the usual sender restrictions. Depending on the setup of the receiver it might even evade spam detection software, so beware…If both postmasters follow the above steps then all emails sent from users of server-A to users of server-B and vice versa will be sent anonymously over Tor.

There is nothing really new in this post, but I couldn’t find any other posts describing such a setup. Since it requires both sides to actually do something for things to work, I don’t think it can ever be used widely, but it’s still yet another way to take advantage of Tor and Hidden Services.

!Open Relaying
When you setup a tor hidden service to accept connections to your SMTP server, you need to be careful that you aren’t opening your mail server up to be an open relay on the tor network. You need to very carefully inspect your configuration to see if you are allowing 127.0.0.1 connections to relay mail, and if you are, there are a couple ways to stop it.

You can tell if you are allowing 127.0.0.1 to relay mail if you have something like this in your postfix configuration by looking at the smtpd_recipient_restrictions and seeing if you have permit_mynetworks, and your mynetworks variable includes 127.0.0.1/8 (default). The tor hidden service will connect via 127.0.0.1, so if you allow that to send without authentication, you are an open relay on the tor network, and you don’t want that…

Three ways of dealing with this.

1. Remove remove 127.0.0.1 from mynetworks and use port 25/587 as usual.

2. Create a new secondary transport that has a different set of restrictions. Copy the restrictions from main.cf and remove ‘permit_mynetworks’ from them
/etc/postfix/master.cf

2525      inet  n       -       -       -       -       smtpd
   -o smtpd_recipient_restrictions=XXXXXXX
   -o smtpd_sender_restrictions=YYYYYY
   -o smtpd_helo_restrictions=ZZZZ

2587 inet n - - - - smtpd
   -o smtpd_enforce_tls=yes
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=XXXXXXX
   -o smtpd_sender_restrictions=YYYYYY
   -o smtpd_helo_restrictions=XXXXX

Then edit your /etc/tor/torrc

HiddenServiceDir /var/lib/tor/smtp_onion
HiddenServicePort 25 2525
HiddenServicePort 587 2587

3. If your server is not used by other servers to relay email, then you can use the newer postfix variable that was designed for restricting relays smtpd_relay_restrictions (remember NOT to use permit_mynetworks there) to allow emails to be “relayed” by the onion service:
/etc/postfix/main.cf

smtpd_relay_restrictions = permit_sasl_authenticated,
        reject_unauth_destination

smtpd_recipient_restrictions =
        reject_unknown_recipient_domain,
        check_recipient_access hash:$checks_dir/recipient_access,
        permit_sasl_authenticated,
        permit_mynetworks,
        permit

Concerns
Can hidden services scale to support hundreds or thousands of connections e.g. from a mailing list ? who knows…
This type of setup needs the help of big fishes (large independent email providers like Riseup) to protect the small fishes (your own email server). So a new problem arises, bootstrapping and I’m not really sure this problem has any elegant solution. The more servers use this setup though, the more useful it becomes against passive adversaries trying to correlate who communicates with whom.
The above setup works better when there are more than one hidden services running on the receiving side so a passive adversary won’t really know that the incoming traffic is SMTP, eg when you also run a (busy) HTTP server as a hidden service at the same machine.
Hey, where did MX record lookup go ?

Trying it
If anyone wants to try it, you can send me an email using voidgrz25evgseyc.onion as the Hidden SMTP Service (in the transport map).

Links:
http://www.postfix.org/master.5.html
http://www.groovy.net/ww/2012/01/torfixbis
ehloonion/onionmx github repository

*Update 01/02/2015 Added information about !Open Relaying and torsocks version 2 configuration*
*Update 11/10/2016 Updated information about !Open Relaying*
*Update 14/06/2018 Added link to ehloonion/onionmx*

Filed by kargig at 22:14 under Encryption,Internet,Linux,Networking,Privacy
Tags: email, hidden service, postfix, Privacy, smtp, tor
6 Comments | 55,611 views

I reported this bug on November 2012 but as of February 2013 it still hasn’t been fixed.

My initial report on oss-security and kernel netdev mailing lists reported it as an ‘information disclosure’ problem but then I found out that the issue is more severe and it can lead to the complete corruption of Linux kernel’s IPv6 stack until reboot. My second report wasn’t public, I thought it would be better not to make any public disclosure until the kernel people had enough time to respond, and was only sent to a number of kernel developers but I’m making it public now since the CVE is already out.

If someone wants to read all the publicly exchanged emails the best resource is probably this: http://marc.info/?t=135291265200001&r=1&w=2

Here’s the initial description of the problem:

Due to the way the Linux kernel handles the creation of IPv6 temporary addresses a malicious LAN user can remotely disable them altogether which may lead to privacy violations and information disclosure.

By default the Linux kernel uses the ‘ipv6.max_addresses’ option to specify how many IPv6 addresses an interface may have. The ‘ipv6.regen_max_retry’ option specifies how many times the kernel will try to create a new address.

Currently, in net/ipv6/addrconf.c,lines 898-910, there is no distinction between the events of reaching max_addresses for an interface and failing to generate a new address. Upon reaching any of the above conditions the following error is emitted by the kernel times ‘regen_max_retry’ (default value 3):

[183.793393] ipv6_create_tempaddr(): retry temporary address regeneration
[183.793405] ipv6_create_tempaddr(): retry temporary address regeneration
[183.793411] ipv6_create_tempaddr(): retry temporary address regeneration

After ‘regen_max_retry’ is reached the kernel completely disables temporary address generation for that interface.

[183.793413] ipv6_create_tempaddr(): regeneration time exceeded - disabled temporary address support

RFC4941 3.3.7 specifies that disabling temp_addresses MUST happen upon failure to create non-unique addresses which is not the above case. Addresses would have been created if the kernel had a higher
‘ipv6.max_addresses’ limit.

A malicious LAN user can send a limited amount of RA prefixes and thus disable IPv6 temporary address creation for any Linux host. Recent distributions which enable the IPv6 Privacy extensions by default, like Ubuntu 12.04 and 12.10, are vulnerable to such attacks.

Due to the kernel’s default values for valid (604800) and preferred (86400) lifetimes, this scenario may even occur under normal usage when a Router sends both a public and a ULA prefix, which is not an uncommon
scenario for IPv6. 16 addresses are not enough with the current default timers when more than 1 prefix is advertised.

The kernel should at least differentiate between the two cases of reaching max_addresses and being unable to create new addresses, due to DAD conflicts for example.

And here’s the second, more severe report about the corruption of the IPv6 stack:

I had previously informed this list about the issue of the linux kernel losing IPv6 privacy extensions by a local LAN attacker. Recently I’ve found that there’s actually another, more serious in my
opinion, issue that follows the previous one. If the user tries to disconnect/reconnect the network device/connection for whatever reason (e.g. thinking he might gain back privacy extensions), then the device gets IPs from SLAAC that have the “tentative” flag and never loses that. That means that IPv6 functionality for that device is from then on completely lost. I haven’t been able to bring back the kernel to a working IPv6 state without a reboot.

This is definitely a DoS situation and it needs fixing.

Here are the steps to reproduce:

== Step 1. Boot Ubuntu 12.10 (kernel 3.5.0-17-generic) ==
ubuntu@ubuntu:~$ ip a ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
    inet6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 fdbb:aaaa:bbbb:cccc:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 fe80::5054:ff:fe8b:995d/64 scope link 
       valid_lft forever preferred_lft forever

ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.lo.use_tempaddr = 2

ubuntu@ubuntu:~$ nmcli con status
NAME                      UUID                                   DEVICES    DEFAULT  VPN   MASTER-PATH
Wired connection 1        923e6729-74a7-4389-9dbd-43ed7db3d1b8   eth0       yes      no    --
ubuntu@ubuntu:~$ nmcli dev status
DEVICE     TYPE              STATE
eth0       802-3-ethernet    connected

//ping6 2a00:1450:4002:800::100e  while in another terminal: tcpdump -ni eth0 ip6

ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=70.9 ms

--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 70.994/70.994/70.994/0.000 ms

# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
17:57:37.784658 IP6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
17:57:37.855257 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:ad1f:9166:93d4:fd6d: ICMP6, echo reply, seq 1, length 64

== Step 2. flood RAs on the LAN ==

$ dmesg | tail
[ 1093.642053] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642062] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642065] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642067] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support

ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = -1
net.ipv6.conf.lo.use_tempaddr = 2

//ping6 2a00:1450:4002:800::100e  while in another terminal: tcpdump -ni eth0 ip6

ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=77.5 ms

--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 77.568/77.568/77.568/0.000 ms

# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
17:59:38.204173 IP6 2001:db8:f00:f00:5054:ff:fe8b:995d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
17:59:38.281437 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:5054:ff:fe8b:995d: ICMP6, echo reply, seq 1, length 64

//notice the change of IPv6 address to the one not using privacy extensions even after the flooding has finished long ago.

== Step 3. Disconnect/Reconnect connection  ==
// restoring net.ipv6.conf.eth0.use_tempaddr to value '2' makes no difference at all for the rest of the process

# nmcli dev disconnect iface eth0
# nmcli con up uuid 923e6729-74a7-4389-9dbd-43ed7db3d1b8

ubuntu@ubuntu:~$ ip a ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
    inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global tentative dynamic 
       valid_lft 86400sec preferred_lft 3600sec
    inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global tentative dynamic 
       valid_lft 86400sec preferred_lft 3600sec
    inet6 fe80::5054:ff:fe8b:995d/64 scope link tentative 
       valid_lft forever preferred_lft forever

//Notice the "tentative" flag of the IPs on the device

//ping6 2a00:1450:4002:800::100e  while in another terminal: tcpdump -ni eth0 ip6

ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
^C
--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
18:01:45.264194 IP6 ::1 > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64

Summary:
Before flooding it uses IP: 2001:db8:f00:f00:ad1f:9166:93d4:fd6d
After flooding it uses IP: 2001:db8:f00:f00:5054:ff:fe8b:995d –> it has lost privacy extensions
After disconnect/reconnect it tries to use IP: ::1 –> it has lost IPv6 connectivity

The problem currently affects all Linux kernels (including the latest 3.8), that have IPv6 Privacy Extensions enabled. The only distribution that has IPv6 Privacy Extensions enabled by default is Ubuntu starting from version 12.04. So Ubuntu 12.04 and 12.10 are currently vulnerable to this attack and can have their IPv6 stack corrupted/disabled by a remote attacker in an untrusted network.

Kernel developers and people from RedHat Security Team are trying to fix the issue which in my opinion involves changing parts of the logic of IPv6 addressing algorithms in the Linux kernel.

No mitigation currently exists apart from disabling IPv6 Privacy Extensions.

You can play with this bug using flood_router26 tool from THC-IPv6 toolkit v2.1.
Usage: # ./flood_router26 -A iface

P.S. I can’t tell if the stack corruption could also lead to other kernel problems, that would probably need some professional security researchers to look into it.

Filed by kargig at 16:27 under Internet,IPv6,Linux,Networking
Tags: 12.04, 12.10, bug, cve, CVE-2013-0343, ipv6, kernel, Linux, Networking, Privacy, privacy extensions, security, slaac, temporary addresses, ubuntu, vulnerability
No Comments | 22,350 views

On Sunday the 11th of November we finally had our first CryptoParty in Athens, Greece. We hosted it at the Athens Hackerspace.

Organizing
We organized our first CryptoParty in a very ad-hoc way. A pad was set up and advertised on Twitter/Facebook. Almost immediately people started writing their thoughts, views and interests there. We soon had a list of topics that people were interested in and another list of people willing to give presentations/workshops. Later on we set up a doodle so people would choose the most convenient dates for them. From the group of 50 people that originally expressed their interest to attend the CryptoParty, at least 20 voted on the doodle. That’s how the final date of November the 11th was chosen.

It was surprising/refreshing that even though everything was organized through an anonymously editable pad, nobody tried to vandalize it.

The actual event
Through the pad, we chose 3 topics for the first meeting. “Using SSL/TLS for your Internet communications”, an “introduction to Tor” and another “introduction to I2P”.
The time for the event was set for 12:00 in the morning, probably a very bad choice. The next one should definitely be later in the afternoon or even night. We learn by our mistakes though…People started showing up at around 11:30, but the event didn’t start until 12:30 when someone from hackerspace.gr gave a 5′ intro talk about what the hackerspace is to people who had never been there before. People kept coming even until 13:00 and the audience had grown to more than 30 people.
After the three workshops/presentations around 10-15 people stayed and we ordered pizza.

All in all I’d say it was fairly successful since more than 30 people came and actually did things to improve their security.

The presentations/workshops
“Using SSL/TLS for your Internet communications” (in English) was my effort to show people how cleartext data travels through the Internet and how any intermediate “bad guy”/LEA can easily read or manipulate your data. People were instructed to install wireshark so they could actually see for themselves what the actual problem is. It was very “nice” to see their surprise upon watching cleartext packets flowing through their network cards. It was even nicer to see their surprise when I used tcpdump on hackerspace’s router to redirect traffic to wireshark running on a Debian laptop to display their data, without having “direct” access to their computer. Then people were introduced to the idea of Transport Layer Security (SSL/TLS), and how HTTPS protects their web data from prying eyes. After this tiny “privacy apocalypse” it was very easy to convince users to install HTTPS-Everywhere. And so they did. Afterwards they got instructions on how they should change SSL/TLS settings for their E-email and IM clients.
My original intention was to “scare” people a bit. It was funny to see their faces when they logged in to yahoo mail and they could see their emails cleartext on wireshark. People don’t understand how data travels through the Internet unless they experience it for themselves. I’m glad that people who had absolutely no idea about HTTPS are now using HTTPS-Everywhere to protect themselves. Hopefully they’ll show that to their friends as well.

“Introduction to Tor” (in Greek) gave people an idea at what anonymity is, how it differs from security and how users should be combining both TLS and Tor usage for security and anonymity at the same time. A brief explanation of what hidden services are was given as well. Even though George asked people to download and install Tor Browser Bundle and use it, we’ll definitely need more “hands on” Tor workshops in the future. It will be interesting to convince more people to actually use it and why not, even set up their own hidden services.

“Invisible Internet Project a.k.a. I2P” (in English) by @alafroiskiotos was probably the hardest of the three presentations to keep up for people that had no previous idea about anonymity networks. It’s unique architecture and some difficulties in it’s usage raised a lot of interesting questions by attendees.

Thoughts on future CryptoParties
After the end of the workshops/presentations we had a lengthy discussion with the attendees as to what they would like to see/experience in the future CryptoParties. Unfortunately people were not very vocal. Very few participated and openly expressed their thoughts/opinions. A great part of the discussion was spent trying to figure out whom should CryptoParty presentations/workshops target at, users? developers? geeks? It’s obviously very hard to target all groups of people at the same time.

So here are my thoughts on what future CryptoParties should be. CryptoParties should be about changing user habits, they should be closer to workshops than presentations. They should be focused mainly on users not developers nor computer science students. Just simple users. People don’t want theoretical talks about cryptography, they need advice they can use in their daily lives. It’s already very hard to talk about modern crypto to people who haven’t got a strong mathematical background, you have to oversimplify things. Oversimplifying things then makes geeks/nerds unhappy and still doesn’t “teach” people about proper crypto. Even a fairly “simple” HTTPS negotiation contains key crypto concepts that are very difficult for a “crypto-newbie” to grasp. So it’s a lose-lose situation.

We need to teach, or better convince, users on using good, secure, audited tools and not just tell them about technologies and concepts. We, weirdos, might like that, but most users don’t. People need our help to learn how to avoid “fancy” tools and false security prophets. We need to show them how security should be applied in a layered approach. Getting people to care about their own privacy is key to the success of CryptoParties in the way I see them. To achieve that, we, people that know a few things more than the average Joe, should all become volunteers to such efforts. We should be joining CryptoParties in order to help others and not in order to improve ourselves and our knowledge. (Actually when you study in order to make a good workshop/presentation you improve your own knowledge as well, but let’s leave that beside for now.) We can have our separate geeky/nerdy events to present fancy tech and cool crypto stuff, but let’s keep CryptoParties simple and practical. Oh and we’ll need to repeat things again and again and again. That’s the only way people might change their habits.

If you want to find out more about the next Athens CryptoParty keep an eye at Hackerspace’s events and the athens cryptoparty pad. Join us!

Good luck to all the CryptoParties worldwide!

Filed by kargig at 21:23 under Encryption,Internet,Linux,Networking,Privacy
Tags: anonymity, athens, CryptoParty, HSTS, https, HTTPS-Everywhere, I2P, Networking, presentation, Privacy, security, SSL/TLS, tcpdump, tor, wireshark, workshop
No Comments | 10,087 views

*WARNING* 14/01/2014 This post is quite deprecated. For example obfsproxy has been completely rewritten in python and there is a newer and more secure replacement of obfs2, named obfs3. Please read this obfsproxy-debian-instructions for any updates.

Some countries like China, Iran, Ethiopia, Kazakhstan and others, like installing some nasty little boxes at the edges of their country’s “internet feed” to monitor and filter traffic. These little boxes are called DPI (Deep Packet Inspection) boxes and what they do, is sniff out every little packet flowing through them to find specific patterns and then they provide their administrator with the option to block traffic that matches these patterns. These boxes are very sophisticated and they don’t just filter traffic by src, dst or port, they filter traffic by the content (payload) the packets carry.
Unfortunately, it’s not just these countries that deploy DPI technologies, but some private companies also use such devices in order to monitor their employees.

The 10 thousand feet view
Tor is a nice way to avoid basic censorship technologies, but sometimes DPI technology is so good that it can fingerprint Tor traffic, which is already encrypted, and block it. In response to that, Tor people devised a technology called Pluggable Transports whose job is to obfuscate traffic in various ways so that it looks like something different than it actually is. For example it can make Tor traffic look like a skype call using SkypeMorph or one can use Obfsproxy to obfuscate traffic to look like…nothing, or at least nothing easily recognizable. What’s cool about obfsproxy though is that one can even use it separately from Tor, to obfuscate any connection he needs to.

A warning
Even though obfsproxy encrypts traffic and makes it look completely random, it’s not a fool proof solution for everything. It’s basic job is to defend against DPI that can recognize/fingerprint TLS connections. If someone has the resources he could potentially train his DPI box to “speak” the obfsproxy protocol and eventually decrypt the obfuscated traffic. What this means is that obfsproxy should not be used as a single means of protection and it should just be used as a wrapper _around_ already encrypted SSL traffic.
If you’re still in doubt about what can obfsproxy protect you from and from what it can’t, please read the Obfsproxy Threat Model document.

Two use cases
Obfuscate an SSH and an OpenVPN connection.
Obviously one needs a server outside the censorship perimeter that he or someone else will run the obfsproxy server part. Instructions on installing obfsproxy on Debian/Ubuntu are given in my previous blog post setting up tor + obfsproxy + brdgrd to fight censhorship. Installing netcat, the openbsd version; package name is netcat-openbsd on Debian/Ubuntu, is also needed for the SSH example.

What both examples do is obfuscate a TLS connection through an obfsproxy server so that it looks innocent. Assuming that the most innocent looking traffic is HTTP, try running the obfsproxy server part on port 80.

SSH connection
Scenario:
USER: running ssh client
HOST_A (obfsproxy): running obfsproxy on port 80 and redirecting to HOST_B port 22
HOST_B (dst): Running SSH server on port 22

What one needs to do is setup the following “tunneling”:
ssh client —> [NC SOCKS PROXY] —> obfsproxy client (USER)—> obfsproxy server (HOST_A) —> ssh server (HOST_B)

Steps:
1. on HOST_A setup obfsproxy server to listen for connection and redirect to HOST_B:
# screen obfsproxy --log-min-severity=info obfs2 --dest=HOST_B:22 server 0.0.0.0:80

2. on USER’s box, then configure obfsproxy client to setup a local socks proxy that will obfuscate all traffic passing through it:
$ screen obfsproxy --log-min-severity=info obfs2 socks 127.0.0.1:9999
Then instead of SSH-ing directly to HOST_B, the user has to ssh to HOST_A port 80 (where obfsproxy server is listening).

3. on USER’s box again, edit ~/.ssh/config and add something along the following lines:

Host HOST_A
    ProxyCommand /bin/nc.openbsd -x 127.0.0.1:9999 %h %p

This will force all SSH connections to HOST_A to pass through the local (obfsproxy) socks server listening on 127.0.0.1:9999

4. Finally run the ssh command:
$ ssh -p 80 username@HOST_A

That’s it. The connection will now pass get obfuscated locally, pass through obfsproxy server at HOST_A and then finally reach it’s destination at HOST_B.

OpenVPN connection
Scenario:
USER: running OpenVPN client
HOST_A (obfsproxy): running obfsproxy on port 80 and redirecting to HOST_B TCP port 443
HOST_B (dst): Running OpenVPN server on port 443

What one needs to do is setup the following “tunneling”:
openvpn client —> obfsproxy client (USER)—> obfsproxy server (HOST_A) —> OpenVPN server (HOST_B)

Steps:
1. on HOST_A setup obfsproxy server to listen for connection and redirect to HOST_B:
# screen obfsproxy --log-min-severity=info obfs2 --dest=HOST_B:443 server 0.0.0.0:80

2. on USER’s box, then configure obfsproxy client to setup a local socks proxy that will obfuscate all traffic passing through it:
$ screen obfsproxy --log-min-severity=info obfs2 socks 127.0.0.1:9999
Then instead of connecting the OpenVPN client directly to HOST_B, the user has edit OpenVPN config file to connect to HOST_A port 80 (where obfsproxy server is listening).

3. on USER’s box again, edit your openvpn config file, change the ‘port’ and ‘remote’ lines and add a ‘socks-proxy’ one:

port 80
remote HOST_A
socks-proxy 127.0.0.1 9999

This will instruct the OpenVPN client to connect to HOST_A passing through the local (obfsproxy) socks server listening on 127.0.0.1:9999

4. Finally run the openvpn client command:
$ openvpn client.config

That’s it.

Security Enhancement
You can “enhance” obfproxy’s security by adding a shared secret parameter to command line, so anyone who doesn’t have this secret key won’t be able to use the obfsproxy server, decryption of packets will fail:
# screen obfsproxy --log-min-severity=info obfs2 --shared-secret="foobarfoo" --dest=HOST_B:443 server 0.0.0.0:80
$ screen obfsproxy --log-min-severity=info obfs2 --shared-secret="foobarfoo" socks 127.0.0.1:9999

Documentation
Or at least…some documentation.

Your best chance to understand the internals of obfsproxy is to read the protocol specification

For more info about obfsproxy client part, read the documentation here: obfsproxy client external
For more info about obfsproxy server part, read the documentation here: obfsproxy server external

Screenshots
For those who like meaningless screenshots, here’s what wireshark (which is certainly NOT a DPI) can tell about a connection without and with obfsproxy:

Without obfsproxy

With obfsproxy

*Update*
one can find openvpn configuration files for use with obfsproxy here:
Linux Client
Windows Client

Filed by kargig at 01:54 under Encryption,Internet,Linux,Networking,Privacy
Tags: censorship, china, debian, Encryption, firewall, gfw, Linux, Networking, obfsproxy, openvpn, Privacy, security, ssh, tls, tor, vpn
5 Comments | 70,441 views

*WARNING* 14/01/2014 This post is quite deprecated. For example obfsproxy has been completely rewritten in python and there is a newer and more secure replacement of obfs2, named obfs3. Please read this obfsproxy-debian-instructions for any updates.

*Updated* look at the bottom for list of changes

This post is a simple guide to create a debian/ubuntu packages out of the latest versions of Tor, obfsproxy and brdgrd in order to setup a “special gateway” and help people who face censorship issues. Sharing some of your bandwidth helps a lot of people get back their freedom.

Tor
I guess most people already know what Tor is, quoting from Tor’s website:

Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. It also enables software developers to create new communication tools with built-in privacy features. Tor provides the foundation for a range of applications that allow organizations and individuals to share information over public networks without compromising their privacy.

obfsproxy

obfsproxy is a tool that attempts to circumvent censorship, by transforming the Tor traffic between the client and the bridge. This way, censors, who usually monitor traffic between the client and the bridge, will see innocent-looking transformed traffic instead of the actual Tor traffic.

brdgrd

brdgrd is short for “bridge guard”: A program which is meant to protect Tor bridges from being scanned (and as a result blocked) by the Great Firewall of China.

Combining these to work together is quite easy if you follow this simple guide/howto.

////// Become root
$ sudo su -

////// Get build tools/packages
# cd /usr/src/
# apt-get install build-essential libssl-dev devscripts git-core autoconf debhelper autotools-dev libevent-dev dpatch pkg-config
# apt-get install hardening-includes asciidoc docbook-xml docbook-xsl xmlto
# apt-get install screen libnetfilter-queue-dev

////// Get latest versions of tor/obfsproxy/brdgrd
# git clone https://git.torproject.org/debian/obfsproxy.git
# git clone https://git.torproject.org/debian/tor.git
# git clone https://git.torproject.org/brdgrd.git

////// Compile obfsproxy & create package
# cd obfsproxy/
# ./autogen.sh 
# debuild -uc -us 

////// Compile tor & create package
# cd ../tor/
# ./autogen.sh 
# debuild -uc -us 

////// Install packages
////// The following package versions might be different depending on your configuration. Change them appropriately by looking at the deb files in your path: ls *.deb

# cd ..
# dpkg -i tor-geoipdb_0.2.4.3-alpha-1_all.deb obfsproxy_0.1.4-2_amd64.deb tor_0.2.4.3-alpha-1_amd64.deb

////// Create Tor configuration
////// PLEASE SEE THE CHANGEME_X VARIABLE BELOW BEFORE RUNNING THE FOLLOWING COMMAND

# cat > /etc/tor/torrc << EOF 
AvoidDiskWrites 1
DataDirectory /var/lib/tor
ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed
Log notice file /var/log/tor/notices.log
## If you want to enable management port uncomment the following 2 lines and add a password
## ControlPort 9051
## HashedControlPassword 16:CHANGEME
## CHANGEME_1 -> provide a nickname for your bridge, can be anything you like.
Nickname CHANGEME_1
## CHANGEME_2 -> How many KB/sec will you share. Don't be stingy! Try putting _at least_ 20 KB.
RelayBandwidthRate CHANGEME_2 KB
## CHANGEME_3 -> Put a slightly higher value than your previous one. e.g if you put 500 on CHANGEME_2, put 550 on CHANGEME_3.
RelayBandwidthBurst CHANGEME_3 KB
ExitPolicy reject *:* 
## CHANGEME_4 -> If you want others to be able to contact you uncomment this line and put your GPG fingerprint for example.
#ContactInfo CHANGEME_4
ORPort 443 
#ORPort [2001:db8:1234:5678:9012:3456:7890:1234]:443
BridgeRelay 1
## CHANGEME_5 -> If you don't want to publish your bridge in BridgeDB, so you can privately share it with your friends uncomment the following line
#PublishServerDescriptor 0
EOF

////// Restart Tor

# /etc/init.d/tor restart

////// Compile and run brdgrd
////// If you've changed ORport in Tor config above, be sure to change the "--sport 443" port below as well
////// brdgrd does not help since obfsproxy is already running in front of the bridge, but won't hurt either.

# cd brdgrd/
# make
# iptables -A OUTPUT -p tcp --tcp-flags SYN,ACK SYN,ACK --sport 443 -j NFQUEUE --queue-num 0
////// brdgrd Can't do IPv6 yet...so the next line is commented out
////// ip6tables -A OUTPUT -p tcp --tcp-flags SYN,ACK SYN,ACK --sport 443 -j NFQUEUE --queue-num 0
////// You can run brdgrd without root, just by setting some correct cap_net_admin rights
////// Instead of: screen -dmS brdgrd ./brdgrd -v
$ sudo screen -dmS brdgrd setcap cap_net_admin=ep ./brdgrd -v

# tail -f /var/log/tor/notices.log

The above guide has been tested on Debian Squeeze and Ubuntu 12.04.

That’s it. You just made the world a better place.

*Update*
I’ve made some changes to the post according to comments on the blog post and #tor-dev.
a) Changed URLs for the git clone operations to https:// instead of git://
b) Changed brdgrd git url to gitweb.torproject.org instead of github.
c) Changed config sections of torrc file
d) Added some more info on brdgrd

*Update2*
Tor has published “official” instructions for setting up obfsproxy bridges on Debian boxes –> Setting up an Obfsproxy Bridge on Debian/Ubuntu

*Update3*
Update sample config to inform about unpublished bridges.

Filed by kargig at 18:50 under Encryption,IPv6,Linux,Networking,Privacy
Tags: 12.04, brdgrd, bridgedb, censorship, debian, guide, HOWTO, ipv6, Linux, obfsproxy, Precise Pangolin, Privacy, Squeeze, tor, ubuntu
7 Comments | 30,871 views

HTTPS Everywhere is a browser addon by EFF whose job is to redirect you to the HTTPS versions of certain, whitelisted, web sites. What this means is that HTTPS Everywhere protects your communication with those websites by forcing them to be encrypted.

The current HTTPS Everywhere ruleset lacks any Greek websites, so I started yet-another-list to create rules for Greek websites. This is the fourth list I’m maintaing after GrRBL, Greek Spammers Blacklist and Greek AdblockPlus Filter rules and it is the only one where being included is actually a good thing.

You can find some more info about Greek rules for HTTPS Everywhere on my github page.

Until the rules get adopted upstream by HTTPS Everywhere team, in order to use them you should download the rules and place them inside your Firefox profile directory. But first of all you need to install the plugin/extension/addon/call-me-whatever-you-want by going to HTTPS Everywhere page.

Step 1: Instructions for Linux users
Go to the HTTPSEverywhereUserRules directory inside your firefox profile directory:

$ cd .mozilla/firefox/XYZXYZXYZ.default/HTTPSEverywhereUserRules/
(XYZXYZXYZ will be different in your machine)

and download the current Greek ruleset:
$ wget https://raw.github.com/kargig/https-everywhere-greek-rules/master/Greek.xml

Step 1: Instructions for Windows users
Download https://raw.github.com/kargig/https-everywhere-greek-rules/master/Greek.xml with your favorite browser.
Then, according to this Mozilla support page, open Fifefox, go to Help->Troubleshooting Information and under the Application Basics section, click on Open Containing Folder. There a window will appear and you should copy the previously downloaded Greek.xml file inside the HTTPSEverywhereUserRules folder.

Step 2: Instructions for any OS
Either restart your browser to load the new rules or click the HTTPS Everywhere icon beside the url bar, select “Disable HTTPS Everywhere”, then click it again and select “Enable HTTPS Everywhere”. The new rules should now be loaded, you can test by going to http://void.gr and it should immediately redirect you to https://void.gr

Some notes
The ruleset is experimental. If you find any problems please report them as issues to github.
If you want a Greek website added to the list, either report it as a new issue on github or fork the repository, add your own rules and open a pull request.

A small rant
I found some webmails in Greece that don’t even offer HTTPS as an option to the user. They ‘POST’ user details, including passwords of course, over unencrypted HTTP connections. I will be updating a text file called hallofshame.txt inside the github reposity of Greek rules for HTTPS Everywhere with such websites. I am planning to inform the operators of such websites every now and then, so if you know any other cases please open up new issues so we can help protect innocent users.

A big rant on current HTTPS status of top Greek websites
The status of HTTPS support on top 100 Greek websites (according to Alexa) is SAD. No wait, it is EXTEMELY SAD. Out of these 100 websites, taking into account only the ones that are actually run by Greeks, that means excluding Google, Facebook, Youtube, LinkedIn, etc, only 2, yes you read correctly, just two websites offer HTTPS support.
The reason 95% the others don’t is probably because they are based on Akamai-zed services and either don’t have the money to buy Akamai’s HTTPS products or don’t have the technical skills to do it properly.

If you don’t run an Akamai-zed website and want a completely free 1-year SSL certificate please visit https://www.startssl.com/. If you need professional help with your setup please don’t hesitate to contact.

There’s a very good (financial) explanation why these high traffic Greek sites have prefered Akamai’s services and haven’t deployed their own servers in Greece but this will be the content of another blog post coming soon.

Filed by kargig at 19:51 under Encryption,Greek,Internet,Linux,Networking,Privacy
Tags: EFF, Encryption, https, HTTPS-Everywhere, Linux, Networking, Privacy, security, ssl, tls
2 Comments | 18,409 views

Από δελτίο τύπου του Οργανισμού Πνευματικής Ιδιοκτησίας:

…στις 16 Μαΐου 2012 δημοσιεύθηκε η απόφαση 4658/2012 του Μονομελούς Πρωτοδικείου Αθηνών, η οποία έκανε δεκτό αίτημα οργανισμών συλλογικής διαχείρισης δικαιωμάτων επί μουσικών και οπτικοακουστικών έργων να υποχρεωθούν εκτός άλλων οι ελληνικές εταιρίες παροχής υπηρεσιών σύνδεσης στο διαδίκτυο να λάβουν τεχνολογικά μέτρα προκειμένου να καταστεί αδύνατη η πρόσβαση των συνδρομητών τους σε διαδικτυακές τοποθεσίες μέσω των οποίων πραγματοποιείται παράνομη παρουσίαση και ανταλλαγή έργων. Η απόφαση εφαρμόζει ουσιαστικά για πρώτη το άρθρο 64 Α του ν. 2121/1993 που ενσωματώνει πρόβλεψη Οδηγίας της Ευρωπαϊκής Ένωσης για τη δυνατότητα λήψης ασφαλιστικών μέτρων κατά των διαμεσολαβητών (παρόχων υπηρεσιών διαδικτύου), οι υπηρεσίες των οποίων χρησιμοποιούνται από τρίτο για την προσβολή του δικαιώματος του δημιουργού ή συγγενικού δικαιώματος. Παρόμοιες αποφάσεις έχουν ήδη εκδοθεί σε άλλα κράτη μέλη της Ευρωπαϊκής Ένωσης και αποσκοπούν στην προστασία της πνευματικής ιδιοκτησίας στο διαδίκτυο χωρίς να θίγονται τα δικαιώματα των χρηστών….

Την πλήρη απόφαση μπορείτε να την διαβάσετε εδώ: 4658/2012
*Update*
Επειδή το site του ΟΠΙ δεν παρέχει πια την απόφαση, την έχω ανεβάσει εδώ: Απόφαση-του-Πρωτοδικείου-Αθηνών-για-την-αντιμετώπιση-της-διαδικτυακής-πειρατείας

Γιατί είναι σημαντική αυτή η απόφαση για τους χρήστες
Για πρώτη φορά στην Ελλάδα δικαστήριο επιβάλλει συγκεκριμένα τεχνικά/τεχνολογικά μέτρα παρεμπόδισης της πρόσβασης χρηστών σε ιστοσελίδες/servers. Σήμερα μπορεί να είναι μια ιστοσελίδα που παρέχει “πειρατικό” περιεχόμενο και ο ιδιοκτήτης της βγάζει χρήματα μέσω των διαφημίσεων, αύριο μπορεί να είναι ένα site που ο ιδιοκτήτης του δεν βγάζει χρήματα και μεθαύριο ένα πολιτικό site, ένα θρησκευτικό site, ένα blog που διαφωνεί με τις μεθόδους μιας εταιρίας, μιας κυβέρνησης, κτλ. Οπότε πρέπει ως χρήστες να ξέρουμε τι επιβάλλει το δικαστήριο και να δούμε πως εμείς, ως μέλη της κοινωνίας του Internet, μπορούμε να κάνουμε κάτι για να ακυρώσουμε στην πράξη μια τέτοια απόφαση αν πιστεύουμε πως αυτή είναι λανθασμένη.

Τι περιγράφει η απόφαση
Η απόφαση περιέχει μια λεπτομερή τεχνική έκθεση που εξηγεί πως δουλεύει ένα site, ποια πρωτόκολλα χρησιμοποιούνται από τα μηχανήματα των χρηστών/πελατών για να αποκτήσουν πρόσβαση στο site και έπειτα περιγράφει τρόπους να διακοπεί η σύνδεση των χρηστών με ένα site. Οι τρόποι που παρουσιάζονται είναι οι εξής 2:
Ι) Εφαρμογή κατάλληλων φίλτρων στους δρομολογητές (routers) των ISPs ώστε να αποκλειστεί οποιαδήποτε κίνηση καταλήγει σε συγκεκριμένη IP.
ΙΙ) Εφαρμογή κατάλληλης ανακατεύθυνσης, μέσω τροποποίησης των DNS εγγραφών στους nameservers του κάθε ISP ώστε, ώστε τα αιτήματα προς συγκεκριμένα domains να καταλήγουν σε διαφορετικούς ιστοτόπους. Αυτοί οι ιστότοποι θα μπορούσαν να περιέχουν και ένα προειδοποιητικό μύνημα ώστε να καταλαβαίνουν οι χρήστες γιατί δεν έχουν πρόσβαση στο κανονικό site, όπως αναφέρει το η έκθεση.

Από αυτούς τους 2 τρόπους, στην απόφαση επιβάλλεται η χρήση μόνο του τρόπου (I) ως τεχνολογικό μέτρο διακοπής της πρόσβασης στις “παραβατικές” ιστοσελίδες.

Τα προβλήματα της απόφασης
Τα προβλήματα της απόφασης για μένα είναι αρκετά. Κάποια αναφέρονται και στην ίδια την τεχνική έκθεση που περιέχεται στην απόφαση.
Συγκεκριμένα αναφέρει:

Αν και υπάρχουν δυνατότητες παράκαμψης των συγκεκριμένων τεχνικών μέσων από την μεριά των χρηστών του διαδυκτύου, οι τεχνικές αυτές είναι άγνωστες στη μεγάλη πλειονότητα των πελατών (συνδρομητών) των ISP, που είναι οι δυνητικοί επισκέπτες των ιστοτόπων στους οποίους έχει διακοπεί η πρόσβαση.

Θα αναφερθώ μόνο στα πολύ βασικά όμως…
α) Καταρχήν τα sites έχουν αλλάξει IPs. Το www.ellinadiko.com πλέον δεν δείχνει στην IP που αναφέρεται στην απόφαση, για την ακρίβεια δεν δείχνει πουθενά αυτή τη στιγμή, ενώ το www.music-bazaar.com λειτουργεί αλλά δείχνει σε διαφορετική IP. Άρα η εφαρμογή της οδηγίας (Ι) είναι πρακτικά άχρηστη ως προς τους σκοπούς της απόφασης χωρίς πολλά πολλά. Από την άλλη όμως μπορεί να δημιουργήσει προβλήματα πρόσβασης σε άλλα sites που μπορεί αυτή τη στιγμή να φιλοξενούνται σε εκείνες τις IP για τις οποίες πρέπει να μπουν φίλτρα. Άρα αν εφαρμοστεί η απόφαση ως έχει κινδυνεύει να διακοπεί η πρόσβαση στο site μιας ελληνικής ή ξένης εταιρίας ή προσώπου χωρίς να φταίει σε τίποτα! Ακόμα να μην είχαν αλλάξει IPs τα sites αυτά όμως, πάλι προκύπτει πρόβλημα. Η σύγχρονη τεχνολογία, των τελευταίων 15+ ετών, επιτρέπει την φιλοξενία πολλαπλών ιστοτόπων στην ίδια IP μέσω της τεχνολογίας virtual hosting, κάτι που εφαρμόζεται κατά κόρον ώστε να εξοικονομηθούν IPs. Αυτό έχει σαν αποτέλεσμα πως αν αποτραπεί η κίνηση προς μία συγκεκριμένη IP από ένα φίλτρο ενός ISP, τότε παρεμποδίζεται και η κίνηση προς όλα τα υπόλοιπα sites που φιλοξενούνται στην ίδια IP. Άρα υπάρχει πιθανότητα “τιμωρίας” αθώων ανθρώπων που δεν έχουν κάνει απολύτως τίποτα.

β) Η τεχνική έκθεση και η απόφαση περιέχει συγκεκριμένα domains που θα πρέπει να εφαρμοστεί το (II). Αυτό όμως δεν εμποδίζει σε τίποτα τον διαχειριστή της “προβληματικής” ιστοσελίδας να αλλάξει αύριο domain κρατώντας ακριβώς το ίδιο περιεχόμενο. Οπότε εμποδίζοντας την πρόσβαση στους πελάτες πίσω από ένα ISP σε ένα συγκεκριμένο domain δεν καταφέρνεις και πολλά. Ακόμα όμως και να μην αλλάξει domain ο διαχειριστής μιας και υπάρχουν ελέυθεροι nameservers (Google Public DNS, OpenDNS, κ.α) στο Internet, το μόνο που θα είχε να κάνει ο χρήστης θα ήταν να χρησιμοποιήσει αυτούς έναντι των nameservers του ISP του. Άρα πάλι τα τεχνικά μέτρα είναι εντελώς ανεπαρκή ως προς τον σκοπό της απόφασης. Πέραν αυτού και λόγω της προτεινόμενης ανακατεύθυνσης που προτείνει η τεχνική έκθεση τίθεται και ένα θέμα ιδιωτικότητας σε περίπτωση που εφαρμοζόταν το μέτρο (ΙΙ). Λόγω της ανακατεύθυνσης όλοι οι πελάτες θα “πήγαιναν” σε μία νέα ιστοσελίδα που θα ήταν υπό τη διαχείριση (μάλλον?) του ISP, άρα ο ISP αποκτάει πολύ εύκολα πρόσβαση στο ποιός θέλει να επισκεφτεί τον ιστότοπο αυτό. Τίθεται λοιπόν ζήτημα παρακολούθησης της κίνησης των πελατών. Προσωπικά το θεωρώ απαράδεκτο, όπως απαράδεκτο είναι να προσπαθείς να αλλάξεις τον τρόπο που λειτουργεί το internet. Άλλωστε όπως έχει πει ο John Gilmore:

The Net interprets censorship as damage and routes around it

Μετάφραση:

Το Δίκτυο ερμηνέυει τη λογοκρισία ως ζημιά και δρομολογεί (την κίνηση) γύρω από αυτό (ξεπερνώντας την ζημιά)

Τι θα μπορούσαν να κάνουν οι χρήστες για να παρακάμψουν το “πρόβλημα” αν τους επηρέαζε
Σε περίπτωση εφαρμογής του (II), όπως αναφέρθηκε παραπάνω το μόνο που θα είχαν να κάνουν οι χρήστες θα ήταν να αλλάξουν nameservers στο PC/δίκτυο τους. Αυτό εξηγείται αναλύτικά στις σελίδες της Google Public DNS αλλά και του OpenDNS. Τόσο απλά. Είναι υπόθεση 1 λεπτού αν έχει ο οποιοσδήποτε τις οδηγίες μπροστά του.

Σε περίπτωση εφαρμογής της τεχνικής (Ι) και την στιγμή που το site δεν μπορεί για τους Χ λόγους να αλλάξει IP, αυτό που πρέπει να κάνουν οι χρήστες είναι να χρησιμοποιήσουν κάποιον proxy server, ένα VPN ή κάποιο άλλο δίκτυο που δρομολογεί διαφορετικά τις συνδέσεις τους, για παράδειγμα το Tor. Ο ευκολότερος τρόπος να βρει κάποιος δωρεάν proxies στο δίκτυο είναι να ψάξει στο Google, ενώ η αγορά ενός VPN ξεκινά από τα 3€. Η χρήση του tor είναι πλεόν αρκετά απλή και το μόνο που απαιτείται είναι να κατεβάσει κανείς το Tor Browser Bundle και να τρέξει το Vidalia. Όταν κάποιος τρέξει το Vidalia θα ανοίξει ένας νέος browser (Firefox) και έπειτα η δρομολόγηση των πακέτων προς το site που θέλει να επισκευτεί κανείς γίνεται μέσω του Tor δικτύου το οποίο είναι αρκετά δύσκολο να το σταματήσουν οι ISPs. Σίγουρα πάντως η απόφαση ασφαλιστικών μέτρων 4658/2012 δεν είναι ικανή να σταματήσει το Tor ή οποιονδήποτε άλλο από τους παραπάνω τρόπους παράκαμψης του “προβλήματος”.

Τι πρέπει να γνωρίζουν οι χρήστες του Internet
Οι χρήστες του internet πρέπει να γνωρίζουν πως ανά πάσα στιγμή μια τέτοια απόφαση μπορεί να τους αλλάξει τις συνήθειές τους αλλά και να τους κόψει την πρόσβαση από πηγές πληροφορίας που μέχρι τώρα είχαν ελεύθερη πρόσβαση. Για να μην βρεθούν τελευταία στιγμή να αναρωτιούνται τί και πώς πρέπει να φροντίζουν να ενημερώνονται για τους κινδύνους και τα προβλήματα. Είναι μάλιστα επιτακτικό ο ένας χρήστης να ενημερώνει τους άλλους. Γι αυτούς ακριβώς τους λόγους τους τελευταίους 2-3 μήνες έχει ξεκινήσει μια προσπάθεια ενημέρωσης των Ελλήνων χρηστών για τα ψηφιακά τους δικαιώματα, τους κινδύνους που υπάρχουν στο διαδίκτυο, πως προστατεύει κανείς τα προσωπικά του δεδομένα και πως αποφεύγει προσπάθειες εταιρικής ή κρατικής λογοκρισίας μέσω κάποιων παρουσιάσεων που γίνονται στο hackerspace της Αθήνας. Η επόμενη παρουσίαση γίνεται στις 30/05/2012 και αφορά την χρήση του δικτύου Tor. Όσοι ενδιαφέρονται είναι ευπρόσδεκτοι να έρθουν να ακούσουν και φυσικά να ρωτήσουν για τυχόν απορίες που ίσως έχουν σχετικά με την ψηφιακή τους ζωή.

Οργανωθείτε!
Αν σας ενδιαφέρει να παλέψετε και εσείς για τα ψηφιακά δικαιώματα και τις ελευθερίες στην Ελλάδα καλό θα ήταν να διαβάσετε το κείμενο θέσεων του Δικτύου για την Ψηφιακή Απελευθέρωση (Digital Liberation Network) και αν συμφωνείτε να εγγραφείτε στην mailing list του DLN.

Filed by kargig at 21:06 under Encryption,General,Greek,Internet,Linux,MacOSX,Networking,Privacy
Tags: 4658/2012, access list, censorship, dns redirection, freedom_of_speech, google dns, Greek, hackerspace, Networking, opendns, Privacy, proxy, security, tor, vpn, ανακατεύθυνση, λογοκρισία, ΟΠΙ
10 Comments | 20,067 views

Say that a user has an email account at the company he works for. Before going on vacation he activates his cool “vacation auto-reply” feature that adds

Out of Office – I will be back from holidays at the end of July.

on the top and then quotes the email he was sent.

During his vacation, he receives a call and he is told he has to urgently sent an email about some financial updates. He rushes to an internet cafe and sends the email. He makes a mistake though and mistypes one of the email addresses of the recipients. Instead of sending the email to “user@domain.com” he sends it at “usar@domain.com”.

His company’s SMTP server though receives the following error message from the remote SMTP server while trying to deliver the email:

<usar@domain.com>: host mx.domain.com[1.2.3.4] said: 550 5.1.1
   <usar@domain.com>... User unknown (in reply to RCPT TO command)

This means that his SMTP server will then send an email to him informing him about the error and quoting parts if not all of the email he had previously sent. The email will likely appear to be from “postmaster@company.com” or “do-not-reply@company.com” or something similar.
It will look like this:

This is the mail system at host mail.company.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                  The mail system

<usar@domain.com>: host mx.domain.com[1.2.3.4] said: 550 5.1.1
   <usar@domain.com>... User unknown (in reply to RCPT TO command)
Reporting-MTA: dns; mail.company.com
X-Postfix-Queue-ID: AE4812AE328
X-Postfix-Sender: rfc822; employee1@company.com
Arrival-Date: Thu,  5 May 2011 20:05:27 +0200 (CEST)

Final-Recipient: rfc822; usar@domain.com
Original-Recipient: rfc822;usar@domain.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.domain.com
Diagnostic-Code: smtp; 550 5.1.1 <usar@domain.com>... User unknown

From: Loyal Employee <employee1@company.com>
Date: July 5, 2011 9:05:29 PM GMT+03:00
To: User User <usar@domain.com>
Subject: Re: Financial updates

Financial data goes here

But the user has still his vacation auto-reply turned on, so when the automatic postmaster’s email reaches his mailbox, the system will automatically reply back to the “postmaster@company.com” quoting the previous email and adding his auto-reply message:

Out of Office – I will be back from holidays at the end of July.

So the postmaster@company.com currently has all the financial details that he shouldn’t!

Apart from the fact that the user was sending financial data to somebody else in a clear text email instead of an encrypted one, the second biggest mistake that the user has made was that he has enabled vacation auto-replies that quote the email he was previously sent. That’s very very wrong. If you don’t want sensitive stuff ending at the postmaster’s inbox avoid quoting previous emails in your auto-replies by all means.

Based on a true story 🙂

Filed by kargig at 12:20 under Internet,Privacy
Tags: auto-reply, email, Privacy, vacation
2 Comments | 15,180 views

I have an OpenVPN server that has the push "redirect-gateway" directive. This directive changes the default gateway of the client to be the OpenVPN server, what I wanted though was to connect to the VPN and access only a specific subnet (eg. 100.200.100.0/24) through it without changing the server config (other people use it as a default gateway).

In the client config I removed the client directive and replaced it with these commands:
tls-client
ifconfig 172.18.0.6 172.18.0.5
route 172.18.0.0 255.255.255.0
route 100.200.100.0 255.255.255.0

What the previous lines do:
tls-client: Acts as a client! (“client” is an alias for “tls-client” + “pull” … but I don’t like what the pull did–>it changed my default route)
ifconfig 172.18.0.6 172.18.0.5: The tun0 interface will have ip 172.18.0.6 on our side and 17.18.0.5 on the server side. The IPs are not random, they are the ones OpenVPN used to assign to me while I was using the “client” directive.
route 172.18.0.0 255.255.255.0: Route all packets to 172.18.0.0 on the tun0 interface. In order to access services running on the OpenVPN server (172.18.0.1) I needed a route to them.
route 100.200.100.0 255.255.255.0: Route all packets to 100.200.100.0 on the tun0 interface

A traceroute to 100.200.100.1 now shows that I accessing that subnet through the vpn.

Filed by kargig at 11:25 under Linux,Networking,Privacy
Tags: client, Linux, Networking, openvpn, Privacy, route, server, vpn
5 Comments | 30,042 views