Security

Implicit SSL in .net / c#

by admin on

The web is a place full of standards and best practices. And then there are those unfortunate developers who has to implement something without any possibility to choose – nor the programming language,nor the server. So sometimes a system administrator has to investigate the reason why something that simply should work is simply not working and has to dig through protocols and servers and code in languages he doesn’t know because it MUST WORK BY TODAY.

So, the problem was that we had a webapp which sent mails through a provider. After a change in management the same portal had to send mails through another provider. Well, the portal is developed in .NET , it is already working, it is using standard libraries, just change all credentials and server name. It should be easy, right?

Wrong. For some reason, it isn’t working. I don’t have such an expertise in mail and related protocols, so I started to limit the boundaries of what could have been. Immediatly I found out that the server was up and running,and I could reach it both on the server and on the client (no firewall nor environment involved). In fact, using a particular combination of ports and protocols I was even able to send and email.
So likely it is a problem in the code. So I put myself to remember the little c# I once used, and studied how to use the library.

QUICK ANSWER

Simply put, there are two kinds of SSL encryption, which is used by SMTPS protocol: implicit and explicit. And Microsoft System.Net.Mail supports just explicit mode, as specified here: Microsoft MSDN Blog . And as always when there’s an important feature, used by a good part of the web, missing from a library, it’s “by design”.

So, what can you do? Well, you can use the fantastic (and DEPRECATED!!) System.Web.Mail . Here you can find an example of how to use it: Forum ASP.NET . Otherwise there are some other third part library, but I cannot suggest anyone of them, I didn’t tried them.

LONG ANSWER

Soon after starting debugging I found out that System.Net.Mail is the standard library in C# to send emails. Maybe it is a little cumbersome and not very easy to use, but it is around by 10 years at least, so any bug should be resolved. Syntax is ok, and logic seems ok too. The behaviour is strange anyway. Let’ summarize:
– On port 25, plain old unencrypted SMTP is working – but a requirement is that mails are encrypted.
– On port 25, SMTPS (encrypted SMTP) doesn’t work; the connection timed out.
– On port 465, SMTP answers with “connection refused”. So the server it’s there, but doesn’t like the way we communicate.
– On port 465, SMTPS connection timed out.
– On port 587, any connection is refused.
Maybe you start to see the pattern. At this point I started to suspect it had something to do with encryption.
So,after some test changing encryption algorithms, I asked Mother Google if she knew anything about SMTPS in C# with the provider Aruba. A LOT of digging – it was a really difficult google fu this time – brought me in the right direction. It seemed that to send via Aruba you had to use another .NET library, the old and deprecated System.Web.Mail. Why? That was even harder to find out.
In the end I discovered that there are two kinds of SSL encryption, called IMPLICIT and EXPLICIT.
In general, in Implicit SSL the first step is always to create an encrypted communication tunnel between client and server; then begins the communication in the requested protocol. HTTPS, for example, always works this way: every message sent by client and by server is encrypted. Regarding other protocols, there’s an implicit SMTPS, an implicit FTPS and an implicit POP3S. All these protocols use a dedicated port, different from the unencripted one.
Explicit SSL works in a slightly different way. The first messages sent are on an unencrypted channel (say, classic port 21 for FTP and 25 for SMTP), then the client asks for encryption (for example, issuing the command SMARTTLS in SMTP) and finally the communication channel is switched on another port (depending on the protocol. standard or agreed during communication), this time with encryption first.
For SMTP, just to summarize, here is what happens:
– an initial SMTP connection is created unencrypted on port 25
– the client send the command STARTSSL
– a new encrypted connection is created on another port (say, 465 or 587)
Obviously after that I found out that Aruba SMTP server only supports implicit SSL encryption. I think that is because a specific kind of email (called PEC), the only one which has legal validity in Italy, is technically regulated by Italian Law. Aruba is one of the major provider of PEC, and I think they decided to use the same technical standard for all emails. In any case, it is nothing particularly strange: SMTP with implicit SSL encryption. Even GMail uses it, if I don’t mistake, on port 587. Anyway, System.Net.Mail does not support it, so you have to use a deprecated or a third part library.

EVEN MORE IN DEPTH

I think that all of this mess comes from this couple of RFC article: IETF – RFC4217 and IETF – RFC2228. Without going too much into details, they regulates how to use encryption in general and SSL in particular with FTP. Yes, you read right, not SMTP, FTP. From what I understood, alse from other articles, it seems that IETF at the time (somewhere between 1997 and 2005 – about 10 to 20 years ago) favoured EXPLICIT over IMPLICIT SSL connections for two main reasons:

  • It simplified the implementation by existent software, not having to rewrite everything but simply adding this functionality in case a specific command was issued;
  • It reduced the proliferation of assigned ports in the reserved range (1 – 1024). This was because for every protocol an implicit SSL version required a dedicated port, effectively doubling the number of ports required.

In the meantime, internet happened. There was a proliferation of protocols, implementations (public and proprietary), and of security issues. And then, Microsoft decided “by design” (if you believe that) that they should follow an IETF specification regarding the FTP protocol for their SMTP library. Yes, that’s madness. In fact, the conseguences of this choice is that for the last 10 years this library was useless for half of the SMTPS servers available on the internet, and that a deprecated library (with all the problems it involves) is still widely.

Well done, Microsoft.

In the last few days there was another hack. 45 million accounts stolen, weak cyphers and decrypted passwords. With Linkedin, MySpace (discovered after years!), Adobe, VK and too many others, according to website haveibeenpwned.com we are above 1 BILLION accounts stolen. It is a real, really big problem. There’s something simply not working with all of this. And I’m just tired of hearing “Never user the same password on different accounts”, it is just plain crazy to have to remember something like 200 passwords, one for every account I have. Moreover, nowadays every fucking website wants you to create an account, and you cannot use their service without it.

Well, let’s start from here.

Why do you need an account? A fairly general reason is to assure that you are allowed to use the service. Maybe you have to pay, or maybe, like in a blog, only few or one person can access a management console. What’s the general rule? YOU HAVE TO IDENTIFY YOURSELF. User and password is a simple way to prove to the website that is really you that is trying to access that reserved area. The concept at the bases is the identity.

How can you prove your identity? Remember, the process to prove an identity implies that there’s someone else besides you, that this someone knows something about you, and that this something is sufficient to prove that you is really you.

Philosophically, as I found in information technology studies, there are only 3 ways to prove it: show something you know, show something you have, show something you are. This is the base, from here we can build up.

Just as an example, imagine for a moment an old world, a world before the digital era. Imagine, let’s say, a military camp in times of war. A messenger comes in, he says he’s bringing new orders from the general. How can the commander of the camp be sure that he is really a messenger and not an enemy spy, bringing false orders? Well, one way could be a set of words, or phrases, chosen before the separation of the two contingent, kept well guarded, known only to the commanders and the messengers. It’s not very foolproof, a man could be captured and tortured to say that password – something the messenger knows. Another way is to show the message: it should be sealed with the unique seal and maybe wax of the general. The symbol of the seal must be well known and difficult to reproduce; moreover the handwriting and the sign could be used if they are well known – something the messenger has. One last way, to be way more sure, is to find someone in the camp that recognizes the messenger, maybe someone that served with him in another camp – something he is.

These are just three examples; maybe it could happen something else, but it will inevitably fall within one (or more) of these three categories. A savvy commander would probably prefer to have all three proofs, if possible.

Let’s come back to our dangerous digital era, and access to Facebook. First thing, you write your username, that is who you claim you are. Now you have to prove that is really you trying to access, so you enter your very difficult password. You are writing something you know. Then you remember that you’re at work, so to start working you have to log to the corporate network plugging in your PC your security token  – something you have. You have to go to the bathroom, so you lock your PC; when you come back, to unlock it you use Windows Hello, a facial recognition system – something you are.

In the military camp example I introduced another concept: the trusted third party. It is the soldier who knows the messenger. Let’s expand with another example: like in the best movies, a New York criminal wants to trade drugs. He has to buy it from some Chinese mafia member that he doesn’t know and doesn’t trust. What does he do? He contacts a local politician that knows both – and obviously can reassure both parts that they aren’t police under cover or something else. The important part for this article is that the New York criminal trusts the politician, and that the politician knows the chinese.

Coming again in our incredibly dangerous digital world, we do (or better, the browser does) the same as above when we visit an HTTPS website. We don’t know if PayPal website is really PayPal and not some phishing attempt, but Symantec, a well known and trusted antivirus producer and certification authority, says that it is really PayPal, and we trust them.

Now we have a general view of all the basic concepts on how to prove our identity. Passwords in today’s world are largely the most used method, basically because it is very simple to implement and because it can be managed only on the website side: there’s no need for special devices to read fingerprints or cards and card readers. There are a lot of other reasons, I’ll talk about them in the next article. Anyway, when we go to into the web, a password it is also most easily broken by persons – or programs – that pretends to be you.

 

MORE IN DEPTH

  • https://www.cs.cornell.edu/courses/cs513/2005fa/nnlauthpeople.html
  • http://www.csoonline.com/article/2976884/data-protection/maybe-it-s-time-to-eliminate-something-you-know-as-an-authentication-method.html
  • http://security.stackexchange.com/questions/69195/why-is-something-you-know-the-weakest-factor-of-authentication

New HTTPS vulnerability: DROWN

by admin on

Another known attack to old SSLv2 … Welcome, if I can say so, to Decrypting RSA with Obsolete and Weakened eNcryption, a.k.a. DROWN .

To Windows Server (2008 up) users, if you didn’t mess too much around with registry keys, SSLv2 should be already disabled.

To Linux/Unix users, you should disable SSLv2 and, if you didn’t already, update OpenSSL to one of the most recent versions. It seems that are vulnerable only versions older than march 2015.

I wouldn’t signore this vulnerability, for,as I understood, it exposes you private key for HTTPS encryption in a very limited amount of time – 8 to 16 hours or even less.

So please disable SSLv2 and check that TLS is not using it for legacy support.

For more information regarding DROWN vulnerability, read this excellent (even if a little technical) article from ArsTechnica.com:

More than 11 million HTTPS websites imperiled by new decryption attack