IT

This is a simple error I got when I tried to run  apt-get update :

Searching the internet for how to solve this problem, I found out a lot of references regarding proxies – which could not be, I was in my home, I had no proxy and other virtual machines were running and updating without any problem. After some more digging (and after a more accurate reading of the the error), I started suspecting something went corrupt – I don’t know how – with the entire gpg key database of apt.

I tried to test it, removing one at the time all rows on /etc/apt/sources.list – and for every one of them the error was the same.

SOLUTION

I found the answer that worked for me here – AskUbuntu – Can’t update my system due to GPG error . Below is the code:

  • apt-get clean removes all files downloaded by apt . When you install a package, apt download all necessary files and put them in a local archive and then installs it. The directory is /var/cache/apt/archives/ . The cleaning in this case is simply to start anew
  • mv is for the same reason as above, to get a clean environment and to force a new download of all lists from the repositories
  • mkdir recreates the moved directory
  • apt-get update is the command that gave the error that started this post 🙂

MORE IN DEPTH

According to this link:  AskUbuntu – Got NODATA issue: ‘NODATA’ (does the network require authentication?) the error could be caused by the ISP (Internet Service Provider) placing a proxy, maybe a transparent one (Maxcdn – Transparent proxy) in front of your connection. I have to dig deeper on this topic, if this is effectively the reason on this error.

Windows 10 Taskbar not working

by admin on

Apparently, one of the many crazy problems of Microsoft Windows. In this case, I had Cortana and the Taskbar Search not working; if I clicked on the taskbar nothing happens. Differently from other cases I found on the web, the menu was working.

SOLUTION

After some digging, I found out this post: Microsoft Answers: FIX – Windows 10 Taskbar Not Functioning  . It wasn’t my case, and besides the solution looked too much complex to me. I didn’t do anything so destructive to my PC to deserve a powershell command line that disabled developer mode for all my apps. What intrigued me was the first line:

***YOU MUST HAVE THE WINDOWS FIREWALL SERVICE RUNNING FOR THIS TO WORK***

Well, in fact I had disabled Windows Firewall service few days ago – an useless service, for I always disable it. It is too messy to use, and it blocks lots of services I have running, adding a layer of complexity to my debug procedure, both on clients and on servers. I dig some more, finding a comment here (the article was useless for my problem, only the comment gave me a confirmation): The Windows Club: Cortana and Taskbar Search not working in Windows 10 by PeacefulArgument which states that simply reactivating Windows Firewall service brought the Taskbar back and working. 

Usually to activate a service I type “service” on the taskbar, but I obviously couldn’t do it, so I had to find another way:

  • Start
  • Scroll down to Windows Administration Tools
  • Click on Services
  • Scroll down to Windows Firewall 
  • Right click -> Properties
  • On Startup Type select Automatic (in my case it was on Disabled)
  • Click on Apply and then Ok

Then I restarted my PC, and the taskbar was working again.

I think even a simple logout and login should work, but in this case you should also start Windows Firewall service:

  • Start
  • Scroll down to Windows Administration Tools
  • Click on Services
  • Scroll down to Windows Firewall 
  • Right click -> Start

 

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.

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