{"id":2044,"date":"2016-01-23T15:55:45","date_gmt":"2016-01-23T13:55:45","guid":{"rendered":"http:\/\/www.void.gr\/kargig\/blog\/?p=2044"},"modified":"2016-01-23T19:15:16","modified_gmt":"2016-01-23T17:15:16","slug":"the-sorry-state-of-starttls-support-of-greek-email-providers","status":"publish","type":"post","link":"https:\/\/www.void.gr\/kargig\/blog\/2016\/01\/23\/the-sorry-state-of-starttls-support-of-greek-email-providers\/","title":{"rendered":"The sorry state of STARTTLS support of Greek email providers"},"content":{"rendered":"

I started looking into the STARTTLS<\/a> 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<\/a> 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.<\/p>\n

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.<\/p>\n

TL;DR<\/strong>
\nThe situation is BAD, REALLY BAD<\/strong>. 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.<\/p>\n

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.<\/p>\n

wtf is STARTTLS?<\/strong>
\n(please don’t read the next sentence if you know what TLS is)
\nIf 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…).<\/p>\n

TLS support per provider<\/strong>
\nThe following is current as of 2016\/01\/23<\/a><\/p>\n

Commercial Providers<\/em>
\nOTE\/COSMOTE<\/a>: Some servers support TLS version 1.0 and some others 1.2 (more on that later)
\nWIND<\/a>: Supports TLS version 1.0 on windtools.gr but does NOT support TLS on wind.gr (different mail servers)
\nCYTA<\/a>: Does NOT support TLS on their mail servers
\nFORTHNET<\/a>: Does NOT support TLS on their mail servers
\nHOL<\/a>: Does NOT support TLS on their mail servers
\nVODAFONE<\/a>: Does NOT support TLS on their mail servers<\/p>\n

non-Commercial Providers<\/em>
\nGRNET<\/a>: Supports TLS 1.2
\nSCH<\/a>: Supports TLS 1.0
\nTEE<\/a>: Does NOT support TLS on their mail servers
\nMIL<\/a>: Supports TLS 1.0<\/p>\n

Universities<\/em>
\nAUTH<\/a>: Supports TLS 1.2
\nNTUA<\/a>: Some servers support TLS 1.0 and one supports TLS 1.2
\nUPATRAS<\/a>: Supports TLS 1.0<\/p>\n

Free Providers<\/em>
\nIN<\/a>: Does NOT support TLS on their mail servers
\nFREEMAIL<\/a>: Does NOT support TLS on their mail servers
\nMAILBOX<\/a>: Supports TLS 1.2<\/p>\n

Radical Providers<\/em>
\nESPIV<\/a>: Supports TLS 1.2<\/p>\n

Certificate status per provider (that have STARTTLS support)<\/strong>
\nOTE\/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.
\nWIND: mx2.windtools.gr uses a valid certificate
\nGRNET: uses a valid certificate
\nSCH: uses a self-signed certificate (which has expired 5 years ago) signed by their own CA (which has expired 4 years ago)
\nMIL: uses a self-signed certificate (which has expired 1 year ago) signed by their own CA
\nAUTH: 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.
\nNTUA: all mail servers use a certificate that is valid for mail.ntua.gr
\nUPATRAS: uses a valid certificate
\nMAILBOX: uses a self-signed certificate (by plesk)
\nESPIV: uses a valid certificate (a wildcard *.espiv.net)<\/p>\n

Why does it matter<\/strong>
\nIt 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.<\/p>\n

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.
\nDear providers, please install a certificate, even a self-signed one, and add support for STARTTLS on your mail servers today.<\/strong><\/p>\n

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.<\/p>\n

Self-signed vs CA-Signed<\/strong>
\nTruth 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?)<\/p>\n

script<\/strong>
\nThe script I used is on github: gr-mx<\/a>. Feel free to make changes and send pull requests.
\nI 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…<\/p>\n

Various weirdness<\/strong>
\n * 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.
\n * mail{5,6,7,8}.dt-one.com mailservers used by OTE\/COSMOTE did not have the self-signed certificate on 2016\/01\/08<\/a> while mail{1,2,3,4}.dt-one.com had it. The certificate was added at some point between 2016\/01\/11<\/a> and 2016\/01\/17<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ep_exclude_from_search":false,"footnotes":""},"categories":[6,11,5,3,8,4],"tags":[618,247,597,616,599,596,617,206,615,488,619],"class_list":["post-2044","post","type-post","status-publish","format-standard","hentry","category-encryption","category-greek","category-internet","category-linux","category-networking","category-privacy","tag-certificate","tag-email","tag-internet","tag-isp","tag-networking","tag-privacy","tag-providers","tag-security","tag-startls","tag-tls","tag-verification"],"aioseo_notices":[],"views":23281,"_links":{"self":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts\/2044","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/comments?post=2044"}],"version-history":[{"count":15,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts\/2044\/revisions"}],"predecessor-version":[{"id":2060,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts\/2044\/revisions\/2060"}],"wp:attachment":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/media?parent=2044"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/categories?post=2044"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/tags?post=2044"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}