Security

Most people just zap the spam as they come in. Typically I inspect each and every incoming one to see if there is slightest bit of interesting in it. Occasionally, if I'm lucky, there is a hijacked web sites or some sort of security mishap going on. However, most of the time I just get a good laugh because the propositions are really silly.

These are the some of the sales pitches the spammers make in attempt to lure me in:

• Congratulations as we wish to inform this email address that you have won on the on-going ASIA PACIFIC Association international promotion email lottery prize draw. In this regards, The beneficiary have been entitled to claim the sum of USD 1,000,000 ( One Million United States Dollars Only ) as cash prize.

  • Comment:
    How nice of that unknown association to arrange a lottery of $10M USD and include me in the games without first asking. Boy, I feel lucky now!

• I am Mr. David Ibe, I work with the International Standards on Auditing, I
  have seen on records, that several times people has divert your funds into their own personal accounts.
  Now I am writing to you in respect of the amount which I have been able to send to you through our International United Nations accredited and approved Diplomat, who has arrived Africa, I want you to know that the diplomat would deliver the funds which I have packaged as a diplomatic compensation to you and the amount in the consignment is £10,000,000.00 (Ten Million Great British Pounds)

  • Comment:
    This is a classic why-an-earth-did-you-pick-me -scenario: Some unknown person wants to transfer a large sum of money and I'll be getting nice slice of that. Boy, I feel so privileged to be chosen here!

• I happen to be a financial adviser and investment planner to the late president of Libya, who was killed in a gun battle in Libya on the 20th of October 2011. I have been handling most of his financial concerns and investment interests here in South Africa up to this date.
  
  I have under my management, some amount of money which the late Gaddafi had instructed me to code for re-investment for his grand children in an event he is caught or killed.
  
  We shall discuss more on this and the amount involved and the remuneration you shall receive for your efforts when I hear from you. Do get back to me.

  • Comment:
    Yet another classic: a dictator is dead and now the money needs to be transferred/invested into something. Lucky me to be involved in such a business venture! There is always something off with the written English, though.

• I am Mr.John Baker from the Office of Inspection Unit/United Nations Agency in John F.Kennedy International Airport New York USA. During my recent routine check at the Airport Storage/vault on withheld packages, I discovered an abandoned shipment that belongs to you from a Diplomat from London and Africa, when scanned it revealed an undisclosed sum of money in two Metal Trunk Boxes weighing approximately 25kg each and some people are coming after this consignment to clam it in your name.
  
  The consignment was abandoned because the Contents was not properly declared by the consignee as “MONEY” rather it was declared as personal effect to avoid interrogation and also the inability of the diplomat to pay for the INTERNATIONAL CONSIGNMENT MONEY MOVEMENT Charges Before bringing in the consignment into US and we refused to return back the consignment where it came from since, we have already received it here in USA.
  
  On my assumption, each of the box contain not less than $5 Million to $5.5Million and the consignment is still left in our Storage House here at the John F. Kennedy International Airport New York USA till date.

  • Comment:
    Oh yes! A huge sum of money was found with my name in the label. Cool! It's kinda weird, because I don't actually know any African diplomats, but still cool!

• Fund Transaction Proposal
  US$23,200,000.00 Million Transaction, for further detail's contact me via my personal e-mail

  • Comment:
    Really short one, I actually included the subject of the e-mail also. Good approach, though. Less words, less lies.

• This is a true compensation Approved from the UNITED NATION to compensate you due to maybe you has been scam before and again you may be victim of scam by wrong people who paraded them selves  on what they are not so because of this, the United Nation approved our Bank to process ATM MASTER CARD with valid cash of usd$2,000.000.00 million on your favor in order to compensate you so that if you have been scammed before this is a compensation and you will be making your withdrawals from the ATM MASTER CARD as you will be allowed in making withdrawals minimum of usd$20,000 (Twenty Thousand usd$) per a day or every 24hrs from any ATM MACHINE around you.

  • Comment:
    Whoa! United Nations is offering me free money, because somebody sent me a spam! And all that without any punctuation in it!!

• Dear Sir/Ma
  We are a financial services and advisory company based in London. Our services have been sought and retained confidentially by a top politician in one of the West-African countries with lot of Money in Cash up to USD $1 Billion (One Billion Dollars Only) for investment purposes. However, our client needs to engage services of a commodity trader, financial adviser, investment banker or a financial institution that they can transfer the funds to their possession to manage for a period of about 10 years.
  Any interested client must travel to meet the representatives of the fund owner to discuss negotiations and have an agreement with them before they release the money to them. If you are interested or can assist in handling this venture, please kindly reply me for further directives. Thanks and best regards. Thomas Bridge 

  • Comment:
    It doesn't get much Nigerian 419 than this: You need to travel to some obscure African country to receive mysterious funds. The sums have gone up, 1bn USD is a lot of dough!

This one is my absolute personal favorite:

In my search for a business partner i got your contact in google search. My client is willing to invest $10 Million to $500 million  but my client said he need a trusted partner who he can have a meeting at the point of releasing his funds.

I told my client that you have a good profile with your company which i got details about you on my search on google lookup. Can we trust you.

Can we make a plan for a long term business relationship.

Comment:
"Because my details were found in a Google lookup, I'm the most trusted partner they could find." REALLY!!?

I don't know how they did it, but I received this e-mail into an e-mail address which I actually use for PayPal activity:

It reads:

Dear Customer !


Recentley we found suspicious activities on your account


So we decided to temporarly suspend your account until further notice


Please click link below and finish requred steps


Click here to update your PayPal account


Sincerely

The fake login site (obviously) doesn't have HTTPS enabled, or the address off http://www.verify-account-login2015centre.-removed-.com/verify-your-account-support/mpp/ doesn't have a single shread of trustworthiness in it. It looks like this:

The website of this login form is badly hacked/broken, the PHP-code on the other end gave only MySQL-error and didn't yield any useful information about it. In any case, I'd be ready to bet some serious money, the website once used to be a WordPress. The hacked sites always are.

Incoming e-mail originated from the same box. And to make sure I got the message, they sent me the same fraud twice. Also very typical for those phishing idiots. It would make the entire thing more believable if they didn't flood my box with the exact copy.

Of course I went to How do I report potential fraud to PayPal? to make sure PayPal gets a chance to shut that stupidity down.

Past two years have been very interesting for anybody in the HTTPS / TLS scene. There have been couple of really serious security flaws and situation is changing constantly for all stakeholders: security researchers are finding these ever-so-critical flaws, software vendors and open-source projects keep updating their products and system administrators try to keep their software patches up-to-date. I guess that wheel of misfortune rolling is a good thing eventually, because the software will be better in the end. However, right now we're in the middle of turbulent Internet security world and that keeps everybody on their toes. Not cool.

Couple of years back I touched the subject in my post. There I was trying to figure out pretty much the same thing, is HTTPS, Mr. Hursti was making noise about SSL being broken. He obviously knew something, but he wouldn't or couldn't share any details. Today we know that he had it right.

Let's walk trough couple of scary-looking terms that in most conditions turn people away.

SSLv1

Encrypted HTTP or HTTPS was invented by Netscape back in 1993. This particular encryption protocol never saw public action and was soon superseded by SSLv2. This was never a standard accepted by others, it was just something Netscape put together in the early days of The Internet.

SSLv2

First ever encryption protocol used in HTTPS. This is what kept us secure between 1994 and 1996 when the design flaws were publicly annouced. There are quite a few of them.

Regardless of these known serious design flaws, there was almost no impact on usage of SSLv2. This is going to sound ridiculous, but lot of sofware run it enabled out-of-the-box for 15 years. For example, the popular Apache HTTPd had it enabled up until version 2.2.22 released in January of 2012. Of course anybody could manually go and disable it also between 1996 and 2012, but who really did? Nobody.

That's the stuff Mr. Scofield's claims of "Internet being broken" and "SSL being worth a post-it note on the NSA" (see my previous post about that).

SSLv3

This is the first serious attempt on securing the internet. Ever since end of 1995 till end of 2014 the protocol was sound. By that I mean by security community. There are claims that number of government-level organizations knew about the design flaws before that.

As all SSL-versions, this was something Netscape cooked in their labs. Rest of the world were lucky to have this, as Netscape released their specs and source code. Still, this is not a standard. This is what people in The Net commonly say: "SSL 3.0 is not a standard. Realistically, it is "what Netscape was doing at that time". When the protocol was turned into a standard, it became RFC 2246, aka "TLS 1.0"".

TLSv1

First ever standard proposed by IETF, the draft is back from 1996. At the time adoption was slow, everybody were using a prefectly good SSLv3 and there was no real need to start using something that was completely overlapping with that.

In 2014, after POODLE-flaw was expanded from SSLv3 to TLSv1, it meant the end of this (in)secure protocol.

TLSv1.1

First ever RFC 2246 back from 2002. Differences between TLSv1 are on the protocol itself and this version didn't introduce any new methods for encryption.

Also TLSv1.1 is suffering from POODLE and using this cannot be considered as secure.

As security adoption through The Net has been really slow, this is the most recent encryption protocol that can be considered as generally adopted by all client implementations roaming the wild-wild-net. Think of this: we're stuck to the year 2002!

TLSv1.2

At the time of writing this post, there are no known protocol design faults in TLSv1.2. This is the level everybody should be using.

The adoption for TLSv1.2 is quite wide, but enforcing it makes no sense for general public. At intranet use, this would make sense, but in the wild-wild-web, there is always some fool running Internet Explorer 6 and complaining, that "your site cannot be accessed".

This protocol, introduced back in 2006, brought a ton of really good encryption and hashing algorithms adding its usefulness. This is the stuff that makes Internet not broken and secure again!

TLSv1.3

This is something for the future. Not even the server running my blog supports this. When looking at the specs, it really doesn't make as big of a leap forward as TLSv1.2 did. It's just to polish and clarify the protocol.

Ciphers

This is the part where I have lost pretty much everybody. For a layman, reading about differences in protocols is as boring as it gets. But when talking about securing HTTP, having a non-flawed protocol is only half of the story. When a client connects the server (this applies to any encryption protocol, SSH, VPNs, etc.), the parties negotiate following details for the connection:

• Function: Key Exchange
  • To keep the connection secure, client and server exchange encryption keys. These keys are used by the bulk cipher. Typically the idea is to keep the exchanged keys as secure and exchange them during connection to make eavesdropping as difficult as possible.
  • Read more at: https://en.wikipedia.org/wiki/Key_exchange
  • Algorithms: RSA, Diffie-Hellman, ECDH, SRP, PSK
• Function: Authentication
  • The idea of authentication is to identify both parties at the time of creating a connection. This is optional. If you think about some of the most popular websites of used in The Net, they don't care about the identify of the connecting client. There are some use cases, where public access is restricted and only authenticated clients may connect.
  • Read more at: https://en.wikipedia.org/wiki/Authentication
  • Algorithms: RSA, DSA, ECDSA
• Function: Bulk Ciphers
  • This is the "beef" of securing a connection. All the data transmitted between parties is encrypted with the purpose of keeping the transmission secure for everybody else.
  • Read more at: IBM's knowledgecenter SSB23S
  • Algorithms: RC4, 3DES, AES
• Function: Message Authentication
  • To avoid any man-in-the-middle -attacks, it is beneficial for both parties to stamp all transmissions by a seal-of-authentication. This is necessary to keep away any third parties trying to tamper or inject any extra traffic into existing connection. This can be considered as "the other party is still the same guy we spoke earlier with and the message hasn't been altered in-transit".
  • Read more at: https://en.wikipedia.org/wiki/Message_authentication_code
  • Algorithms: HMAC-SHA256, HMAC-SHA1, HMAC-MD5

This quadruple is called a cipher suite or cipher for short. It can be used to describe the used algorithms in detail. Also note, that it is possible to run an "encrypted" connection without one or some of the functions. In quotes, because not having message authentication, or a bulk cipher at all is insane. It pretty much defeats the complete idea. Such ciphers do exist in the specification.

This issue of choosing a cipher suite for encrypted communication is vital and overlooked by uneducated sysadmins. Fact is, some ciphers are insecure by design and/or have serious implementation failures.

A complete list of all possible cipher suites is available at IANA web site: Transport Layer Security (TLS) Parameters. It has 326 ciphers defined and starts with the most insecure option there is:
"0x00,0x00",TLS_NULL_WITH_NULL_NULL

The line of 4 NULLs reads: no key exchange, no authentication, no bulk ciphering and no message authentication

Last one in the list is:
"0xCC,0xAE",TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

That reads: RSA key exchange, pre-shared-key authentication, ChaCha20 Poly1305 bulk cipher, with SHA-256 message authentication

Cipher faults

The algorithm issues described below apply to all SSL and TLS protocol versions. You can be using TLSv1.3 and still be at risk of revealing your entire transmission to a listener.

Actually some attack vectors work by targeting a protocol design flaw to use a weaker cipher suite (for example POODLE), thus rendering the entire protocol useless. On the other hand: the attack can be mitigated by disabling any weak ciphers from the system. Sometimes that cannot be done or cannot be done reliably.

RC4 or Rivest Cipher 4 or Arcfour

Using RC4 as a bulk cipher algorithm is stupid, it is one of the oldest algorithms and it's weaknesses are public knowledge. For details, see the article Attack of the week: RC4 is kind of broken in TLS. The short version is, that it is possible to guess the encryption key by simply analyzing encrypted data. Surely the keys will be exchanged eventually, but any listener can guess the next key too.

CBC or Cipher Block Chaining

This is another block cipher. CBC itself isn't flawed. How it was implemented in SSLv3 and TLSv1 is. See article Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures. The attack is quite complex, but it is there. If a 3rd party can alter the packets in transmission, eventually the used encryption key can be calculated from the responses for these packet manglings.

TLSv1.1 actuallyl fixed the flaw in the spec and implementation, but still ... it's game over for CBC. It's hard to find details why, but even the improved CBC3 on TLSv1.1 is flagged as being insecure. That is beyond me why.

SHA-1 or Secure Hash Algorithm 1

SHA-1 is used for message authentication. SHA-1 is the 160 bit version of SHA. The modern versions have 224, 256, 384 or 512 bits for increased security. The weakness of SHA-1 is described in articles When Will We See Collisions for SHA-1? and SHA1 Deprecation: What You Need to Know.

The problem here is, that if you'd have enough money, time and electricity, you could buy 10.000 PCs with super fast GPUs and simply brute force all the possibilities, it would be possible to create a hash collision with some data that would produce the same hash or with luck actually figure out what the original hashed data was. The possibility of somebody doing that is so likely, that this hashing algorithm cannot be trusted anymore. I guess we've learned something from the past?

Final thoughts

The situation isn't that bad. It used to be really bad. If you're one of those luddites running old operating system, old web browser, old cell phone, then you're doomed. Your toys are badly crippled and offer no serious security. You're too ignorant to care, also.

If your gear was released 2-3 years ago, then you're in a good place. Your stuff is configured to run in much smarter way, than the next guy's Windows XP with IE 6.

Technically the situation is bit more difficult. It is pretty much impossible for a Regular Joe, like your and me, to make a choice for the used cipher suite. Protocold dictates, that server is offering the capabilities and the strongest one is chosen. Good thing is that defaults in most commonly used software have improved. A lot, actually. Also lot of public awareness has been raised so, that admins check their settings. But ultimately, it is the system administrator who makes the final say if his/her server is configured to run safely or not.

While at it, I'd like to offer my seal-of-approval to Qualsys SSL Labs and their SSL test service located at https://www.ssllabs.com/ssltest/. That's my #1 weapon-of-choice when testing my server configs. The good thing about that service is, that it is accurate and free-of-charge. Thanks Qualsys for your great service!

Safe browsing to all!