Email, now, is one of the most important
online services that we use.
For most people
it can be a single point of security failure,
because many of our accounts are linked to it.
If you have a email compromise,
your associated accounts are also compromised.
Private information will be compromised,
including your name, address, contacts,
friends and anything else
that’s associated or stored within your email.
It’s obvious to most people
why email security is important,
but email unfortunately is fundamentally broken,
as far as security is concerned,
and it cannot be fixed.
All we can do is keep putting sticky plasters on it.
Plasters which, unless everyone else adopts,
which is pretty much the same as
changing email completely,
we’re just not going to fix
these security problems that are inherent in email.
Email is from a time when security wasn't thought of.
But we continue to use email
because it is ubiquitous,
everybody has an email address now.
If everyone suddenly switched
to a secure messaging alternative tomorrow,
the problem would be solved.
But because that’s not going to happen,
we are stuck with a broken
messaging system called email.
This means you will need to convince others
to adopt encryption technology
if you want to communicate with them privately.
You can't do it on your own.
Let's take it from the beginning.
So there are two ways to access email.
First, you’ve got your web browser
using functionality like HTML5 and JavaScript.
And probably most people now think of that as email,
that is the most common way
that people tend to access email,
you know, via Gmail or Yahoo Mail.
But the second way that is used is an email client,
which is something like Thunderbird, or Claws, or Outlook,
people might use commonly at work.
You have Mac Mail,
or you have the mail apps
that you get on your cell and mobile phones.
Those are all email clients.
And most email providers will allow you
to use both methods, the webmail access
and the email client.
With webmail, you access via HTTPS, port 443,
which is running SSL and TLS encryption,
or at least you should be,
that is the standard solution for most people.
If you’re not, then it’s extremely insecure,
but really, almost all webmail will be encrypted
using HTTPS, port 443, SSL/TLS.
You authenticate that server,
that the server is genuine
via a certificate as is normal with HTTPS,
and the client is authenticated usually with a password.
And if you can,
you should change your authentication method
to be Two Factor Authentication,
as this mitigates password attacks
as we’ve discussed in the Password section.
You should find an email provider
that offers Two Factor Authentication.
If you only use webmail,
then emails are only stored on the server.
And then we have the email client.
With an email client, there are a number of protocols
and port options for both sending and receiving email.
So the options when it comes to receiving mail,
is you have IMAP port 143, which is unencrypted,
you have POP port 110, which is unencrypted;
you don't want to use these.
If you care anything about your email security,
receiving emails, then you don't want to use these,
and most providers now either don't provide them,
or provide encrypted alternatives.
And those alternatives are IMAP port 993,
which is running SSL/TLS encryption
with the certificate based server-side authentication,
like with a website,
and you have POP 3 on port 995,
running the same SSL/TLS encryption
with, again, certificate based server-side authentication.
And those are the two that
you want to go after for receiving email.
IMAP port 993 and POP 3 port 995.
Now, some email providers
may put those on different ports,
but those are the de facto port numbers.
But what is important, is that
they are both running SSL and TLS.
Now, when it comes to the difference
between IMAP and POP,
of the two, IMAP is the popular option
when you need to check your emails
from multiple devices, such as a laptop,
phone, tablet and so on,
because the emails are synced using IMAP
with the server and all devices.
All devices retain copies
with the server having the master copy.
This is the most convenient
and what most people will be used to using.
POP3, alternatively, downloads emails
from the server to a single email client,
then deletes the emails from the server.
Because your messages get downloaded
to a single email client,
and then deleted from the server,
it can appear that the mail is missing,
or disappeared from your inbox
if you try to check your mail
from a different email client or webmail.
But you may want this for security though,
to have no emails stored on the server.
If you’re worried about people accessing the server,
use POP3.
If you’re worried about people accessing your laptop,
store on the server and the client with IMAP.
Then we have the protocols
for sending emails with an email client.
We have SMTP port 25,
which is the original unencrypted port to use;
you don't want to use this if you care about
your emails and sending your emails and privacy.
Then you have something called STARTTLS,
which is usually on port 587.
And that is for using SSL/TLS encryption.
And then you have SMTP port 465,
which again is SSL/TLS encrypted.
You want to use, when it’s possible,
SMPT port 465 with the SSL/TLS.
STARTTLS on 587 is more susceptible
to man-in-the middle attacks.
So go with the SMTP port 465, SSL/TLS option.
For both email clients and webmail,
the SSL/TLS will use a cipher suite, obviously.
You want this to be a good one.
Ideally, using Elliptical Curve Diffie-Hellman,
so the session keys are ephemeral,
so that if the private key is compromised,
only small amounts of data is compromised.
The section on Encryption covers this.
If you remember, back to when we looked at Cipher Suites,
we used a tool called SSL Labs, which is here.
This doesn't scan SMTP or IMAP SSL
mail ports unfortunately, but you can use it
for checking port 443 for webmail.
So for example here, I could check “ghostmail”,
and see how their SSL/TLS stacks up.
And here we go, A+.
Now see, elliptical curve, RSA_WITH_AES,
so yeah, they seem to be doing all the right things there.
And, if you want to examine the other ports like 465, 587,
you’ve got a few options for how you can do that.
One with Kali, is you have SSLscan,
and if you press Return here,
that's just going to simply do port 443.
But if you want to do a special port,
you would do 465,
so then you could look at the SMTP over TLS/SSL.
Just press return here.
And look at there;
because ghostmail only has a webmail interface,
but if they did have port 465 open,
you could check that out.
So here we see what we saw
with SSL Labs, the same Cipher Suites.
Another way of checking out the mail servers
which I like is these guys here.
So if we put in an email address
of someone that you know, and we click Try,
or if you put in even a dummy email address,
if you put test@ghostmail, or gmail,
or what have you, click Try,
it communicates with the mail servers.
It finds out
who the mail server is for that domain,
because it isn't always ghostmail.com, or that domain.
So we can see here,
we have the mail server there, that is taken
from what’s called the MX record for that domain,
MX is the mail record, or mail exchange record.
And what we can see here
is the communication with the mail server,
you can see there, this is using STARTTLS,
and there we can see the Cipher Suite that it uses.
And what you’re actually seeing here is text,
ASCII communication with that port.
So these commands are actually being put
into the package stream for that port.
But I can show you an example of that.
So let's check out maybe Gmail.
So first of all, we need to figure out
what the mail server address is,
so we need to use something called “NSLOOKUP”.
Says is doing a DNS lookup
to check the mail exchange record,
which will give us
the IP address of the mail server for gmail.com.
And there we go,
and we can see actually they’ve got
quite a few which is no surprise.
So to issue text-based SMTP commands,
we need to use some sort of tool that allows us to do that,
we can use Telnet, we can use Netcat.
Netcat is a tool that enables you to read and write
to network connections using TCP and UDP.
So if I go –
So as you can see,
I can just issue standard text commands.
But that is what this is doing,
so I must try that command.
25. Paste. There we go.
So we see we get the same response.
It’s given us some options,
therefore what we want to do.
So STARTTLS, etc.
So, let’s escape out of there.
But yeah, essentially
if we issue the same commands here,
we are going to get the same sort of response.
Now, moving on to Authentication.
For Authentication, as I’ve said,
certificates are used to verify the server,
“is who they claim to be?”
The email client will use his own certificate repository
or that of the operating system,
just the same as a browser does
to validate that the server is who the server is.
So that’s the same as HTTPS,
browsing, server authentication, you know, it’s the same thing.
And we can, of course,
look at the certificates that are on there,
and this is a useful site to do that.
So if we click on “More Detail” here,
let's have a look down.
And there we go,
we can see the first certificate in the chain.
There’s the public key.
And the certificate itself,
and then the second certificate in the chain,
we can see all the way down as to
where the root certificate is.
Client-side authentication.
So depending on the mail client,
you will have different options for authentication,
so those include things like
transmitting the password unencrypted,
which was what was originally done.
And then you’ve got transmitting the password encrypted,
because you’re using SSL or TLS.
You can do things like Kerberos or GSSAPI,
which is something generally used
for enterprise solutions.
You’ve got NTLM,
which is a Microsoft solution
if you’re connecting to exchange servers.
You could use TLS/SSL
or some type of certificate
for your client authentication.
There’s something called OAuth2
that you can use; but generally,
you want to try and use
some form of strong authentication
or two-factor authentication if you can,
and we covered two-factor authentication in its own section.