Tag Archives: SSL

Time to UP the Ante on SSL

As I have been writing about lately, the browser makers, Google and Firefox – and to a much lesser extent Microsoft, are pushing the envelope to get web site operators to switch to always on SSL (AKA HTTPS).  Well, that is a good start, but certainly not the end game.

Why do they care?  Because it is much harder to eavesdrop on HTTPS traffic than it is to eavesdrop on HTTP traffic.  Remember, eavesdropping is a bit of a loose term.  Not only can someone listen in on what you are sending, but they can also fake the RESPONSE back from a web site.  In that case, you THINK that what you are getting back in your browser is coming from a web site you trust, but in reality, you are seeing what the hacker wants you to see.  Sometimes that means changing something here or there, but other times it could mean a wholesale replacement of the web page.

While not impossible to do this under HTTPS (also called SSL or TLS – while there are subtle differences between these, for the purpose of this conversation, they are the same), it is way more difficult for a hacker to do.

But there are a lot of subtleties when it comes to how a web site implements HTTPS.  Most of the time web site operators choose the easiest one;  on rare occasion, they choose the best options.  I will briefly talk about some of the options, but for the most part, it is geek-speak. There is one option that will be the focus of the rest of this post that is important for an end user to understand.

First the geeky part –

There are a number of things that the web site operator should do to enhance security; here are just a couple.  These are out of the user’s control, but we can help the web site operator get closer to the best option instead of the easiest option.

The web site should enable HSTS or HTTP strict transport security.  This ensures that even if YOU don’t enter the S in HTTPS, the browser will do it for you.

HTTP Public Key Pinning – when this is enabled it ensures that an attacker cannot use an SSL certificate obtained illegally from another certificate authority to pretend that they are the site you intend to visit.

Secure cookies – setting secure option helps to protect your information from being stolen by other web sites.

Now here is the part that the user can easily see.

There are two kinds of SSL certificates; one is called domain validation (DV) and the other is called extended validation (EV).

While we talk about the HTTPS encrypting the traffic so that no one can eavesdrop on it, there is another feature of the SSL certificate and that is to ensure that the owner of the web site is, to a much higher level of assurance, who you think it is.

DV certificates ONLY encrypt the traffic to prevent eavesdropping.  Extended validation certificates provide a level of assurance that you are talking to who you think you are talking to.

First, an example.

Here is a screen shot of Vectra Bank’s home page:

Click for a larger view

Notice in the address bar, on the left side, you have the padlock and the word secure.

Here is a screen shot of J.P. Morgan Chase Bank’s home page:

Click for a larger view

Notice to the right of the padlock and the left of the address it says JP Morgan Chase and Co. [US] .

Vectra is using a domain validation certificate and Chase is using an extended validation certificate.

What this means is that you have a higher level of assurance that, when you visit the Chase web site, that it is really owned by JP Morgan Chase and Co.  That is the value of EV certificates.

OK, so that is a theoretical conversation, let’s bring it down to the practical.

Guess how many web sites have an SSL certificate that includes the name PAYPAL?  When you visit Paypal and enter your credit card, you would like to know that it really is The real Paypal.

Maybe 10?  How about 20?  Some of you probably said 1.

The real answer is 15,270.  And that is just from one certificate authority, Let’s Encrypt.  Of those 15,000 plus domains,  over 14,000 were for phishing web sites.

If you are a user and you see the SSL padlock (which is all you get with a DV certificate), you have no way of knowing whether you are visiting a legitimate web site.

Unfortunately, many of the biggies haven’t figured out this is a problem.  Facebook.  Linkedin.  Amazon.  They all use DV certificates.  That could be OK as long as you know what the domain address is and you type it in manually, but for many of these sites, they have related domain names that contain the company’s name but are different from the company’s main web site.

If we use that Paypal example, probably some of those 15,000 plus domains are actually owned by Paypal, but which ones?

The moral of the story is, as a consumer, look for the extended validation and ask questions if you don’t find it.

Information for this post came from Bleeping Computer.


Symantec Issues More Unvalidated SSL Certificates

Symantec, who is already on probation for issuing inappropriate SSL certificates, issued more than a hundred additional “illegit” certificates.

SSL certificates – more technically TLS certificates – are the bits of technology required to make those “secure” web sites work.

Certificates are issued by certificate authorities (CAs) – organizations who have supposedly set up processes and controls to only issue certificates to, for example, the real owners of web sites, among many other rules.

There is a CA oversight board that actually has the authority to shut down CAs who do not follow the rules, but that almost never happens because it would put those companies out of business.

In this most recent case, Symantec was found to have issues at least 108 bogus certificates. 9 of the certificates were issued without the knowledge of the web site owner;  the rest were issued without proper validation.

Some of these bogus certificates were revoked quickly, but some were not.

Even after the certificates are revoked, there are many situations where the bogus certificates might still work in a browser.

This is the reason that there are many rules for CAs to follow.  Only, they don’t always do that.  It is highly unlikely that anything will happen to Symantec as a result of this second bogus certificate issue.  Last year, Symantec issued bogus certificates to Google, among other sites.  Those certificates would allow a hacker, for example, to create a fake GMail site and attract visitors to it.  Anyone who visited the fake site and logged in would have his or her GMail credentials compromised and give the attacker the ability to read all of his or her mail.

The Symantec owned CAs in question are Symantec Trust Network, GeoTrust and Thawte.

After Symantec’s mistake last year, Google required Symantec to log all certificates it issues in a “transparency log” – just so that researchers can check on them.  Whether all of the bogus certificates were caught or not is probably a subject to debate.  Google and the other major browser vendors that run the CA oversight board can dictate to the CAs what they have to do because the browsers have to accept the CA’s master key.  If Google or another browser vendor were to stop accepting Symantec’s master key – as they have done for the Chinese CA WoSign – then all of the certificates that they issue will generate an error message when a user tries to initiate an HTTPS session using that browser.

Given Symantec issues so many certificates, it could fall into the “too big to fail” category, making it hard for the CA oversight board (technically the CA/Browser Forum) to shut them down.

My suggestion is to use a different CA – there are lots of them.  Sending a message with your checkbook is always a prudent practice.

Information for this post came from Ars Technica.

Businesses Get More Time To Upgrade Buggy Encryption Software

The PCI Council, the standards body that dictates the rules for payment card (like Mastercard and Visa) merchants and service providers last year released a directive that everyone had to upgrade their software and eliminate SSL 3.0 and TLS 1.0 in favor of newer versions – TLS 1.1 and 1.2.  The reason was that there are known security holes in those versions of software that are UNFIXABLE – they cannot be patched.  They set a deadline of over a year from when they released the directive for people to fix the problem.

Large organizations apparently complained that they have implemented a bit of a rat’s nest (no big surprise) and with everything else on their plate, they were not going to be able to get to fixing the broken SSL implementations.

As a result, the PCI Council changed the deadline from June 2016 to June 2018 – three years from the original directive.

One thing that is important to understand is that just because the PCI Council changed the date by which, if you have not upgraded, that you will be in violation of your merchant agreement with your bank, you are not relieved of liability in case of a breach.

In fact, I assume that plaintiff’s counsel will be asking if a breached merchant was still running a known vulnerable version of encryption at the time the breach occurred.  One would assume that this would not work to the merchant’s advantage at trial or in settlement negotiations.

Given this announcement, I expect that the hacking enterprises (like China, Russia and Ukraine, for example) will be looking for enterprises that have not upgraded their encryption software and specifically target them.  Given that there are known attacks, that makes these businesses an easy target.

What I am suggesting here is that even though the PCI Council has granted an extension, businesses should not delay their encryption upgrade projects.

The payment card industry, as a whole, spends tens of BILLIONS of dollars a year on payment card fraud.  A 2011 Forbes article says that the industry loses $190 billion a year to credit card fraud.  Even if Forbes has the number wrong by a factor of 2 or 3 too high, that is still a huge number.  That cost is reflected in higher prices and fees that customers – consumers and businesses pay.  By delaying the fix to encryption by two more years, the PCI Council is guaranteeing that the fraud costs will rise over that period and possibly significantly.

Information for this post came from Slashdot and the PCI Council.

Another SSL Attack – But Don’t Panic

SSL and TLS, the security protocols that protect most of our banking and ecommerce transactions is a complicated beast – more so due to the the many options it offers.

ars technica in an article titled “Noose around Internet’s TLS system tightens with two new decryption attacks”, discussed a paper presented at Black Hat Asia that describes a new attack, dubbed the Bar Mitzvah attack (do researchers have contests to come up with strange names?) due the the fact that it has been around for 13 years.

As ars reports, RC4, named after cypto pioneer Ron Rivest of RSA, has been  known to be weak for years.  But weak is a relative term.  One attack, from 2013 required the attacker to see 17 billion encryptions of the same text to reveal SOME of the data in the encrypted stream.

Now researchers have improved that attack.  With only 67 million encryptions, they can recover passwords 50% of the time.

Now a new attack, presented at Black Hat Asia and dubbed the Bar Mitzvah attack, attackers need to sample around a billion encryptions to recover a credit card number.

RC4 is used by around 30 percent of internet TLS (Https) traffic.

As I said above, SSL and its newer cousin TLS have many options.  Some say too many options.  While these attacks don’t seem to present a huge problem if the first attack went from 17 billion encryptions to 67 million in a year, what will next year bring.

The simple solution – like we did for the FREAK attack earlier this year – is to disable known weak ciphers.  But this must be done on the server side for web sites to know they are secure and there is no way for the customer of a bank, for example, to easily know that the banks have disabled these older weaker protocols.  With the FREAK attack, one method of delivery would be for a user of a public WiFi router to be forced to use the weak protocols as a result of a man in the middle attack at that public WiFi access point.

This is why I recommend to NEVER do your banking over a hotel or coffee shop WiFi.  There is a new attack today against a very popular hotel WiFi system (see news here ) for which there is a patch.  However, the researchers who revealed the attack did not say, for security reasons, which hotels of which chains run that system and users have no way of knowing if the hotel has applied the patch.

All this means that IT shops need to spend more time and effort caring and feeding the security components of their server farms.


Is SSL Broken

While every single bank and ecommerce provider tells you that SSL (or HTTPS) is wonderful and fully protects you, unless they are on drugs, they don’t really believe that.  From their perspective, the risk is manageable and they would rather reimburse you if you can prove their SSL connection leaked AND cost you money than tell you that it is not very secure.

Lets remove some of the reasons that people usually give for why HTTPS is not secure and get down to my pet peeve.  First, if you use a public WiFi hotspot, it can execute what is called a man in the middle attack and have your device exchange a handshake with the hotspot instead of the real site.  Your device will never know and the hotspot will see your data in the clear.

Next, there have been many instances of hackers operating fake WiFi hotspots.  Even if the real hotspot is clean, the fake one may execute a man in the middle attack on your traffic.

Next are the bugs in the software.  This year there have been several.  One example is  Heartbleed, which affected the server side of the connection and may have compromised the private half of the SSL lock and key for millions of servers.  Many servers have fixed the problem but many did not bother to create new private keys.  Many have not fixed it.

Next is the problem of revoked certificates.  After Heartbleed was fixed, hundreds of thousands of certificates were revoked because they may have been compromised.  The CRL (certificate revocation list) infrastructure was not and is not designed to handle that.  Firefox uses OCSP, the Online Certificate Status Protocol, but by default, it will accept a certificate if it does not get a speedy response to its request to find out if the certificate is valid.  Some browsers just ignore the CRL question entirely.

Which leads us to my pet peeve.

I looked inside Firefox on my Windows PC today and found HUNDREDS of certificate authorities loaded into the browser.  The Certificate Authority or CA is the (supposedly) trusted organization which certifies that your little SSL padlock – the one that says you are you – is really you.  So who is in the list?  China Telecom.  Hong Kong Telecom. Definitely trust China!  Not!  Actually I did until I deleted their records.  Korea (I hope that would be South and not North).  Many other somewhat friendly countries.  And many that are probably from the U.S. but whom I have never heard of.  I deleted probably 50 of them off Firefox today and there are still more than a hundred active.

Chrome and Internet Explorer use a different CA list than Firefox does.  Apple has their CA list.  If you delete it from your home computer that does not delete it from your phone.  Or your tablet.  Or your laptop.  Think of all the devices that your family uses and you are probably talking well over 1,000 trusted CAs (of course there is a bunch of overlap, but that doesn’t really matter, because even if you tell your desktop you don’t trust China Telecom, you also have to separately tell your phone and your tablet and if you use Chrome and Firefox both, you have to tell each of them separately, even on the same device).

If I had my way, I would have 4 or 5 entries in there and kiss the rest goodbye.

Of course, there is not a decent user interface to manage that and I don’t know, but would not be surprised, if after firefox does an update, China is back.   I will have to test that theory.

Many people agree that SSL is hopelessly broken.  Here is an article from The Register on the subject.  I Googled “is SSL broken” and got 12,400,000 hits.

The bad news is that no one is working on a replacement and even if they did, it would take years to get everyone to agree to it and then we would need to figure out how to do the transition.

Which is why the merchants all cross their fingers behind their backs and say “sure;  it’s secure”.



Is your encryption secure? – Sure, just like flying pigs (keep reading)

Der Spiegel wrote an article on efforts by the NSA and GCHQ (their British equivalent) to crack encryption of various sorts.

Take the article at what it is worth;  it is based on documents that Snowden released, so it is a little bit old.

I apologize that this post is pretty long, but there is a lot of information in the article and I think it is useful to understand what the state of the art is.  If you think the NSA is, in any way, trying to accomplish different goals than say the Russian FSB, then you are wrong. They are likely ahead of the hacker community only because they have a $10 billion annual budget.

For most people, keeping the NSA out is not your goal, but if the NSA figures out a sneaky way to break something, it is likely that, at some point, a hacker may figure it out too.  If the NSA has to spend a million dollars to crack something, that is probably out of the realm of possibility of the hackers – until next year when it costs a quarter of that.  Unless, of course, that hacker works for an unfriendly government.

The Cliff Notes version goes like this.  If you want a longer version, read the article :).  When I refer to the NSA below, I really mean all the NSA like agencies in every country, friendly or not.

  • Sustained (meaning, I assume, ongoing) Skype data collection began in February 2011, according to an NSA training document.  In the fall of 2011, the code crackers declared their mission accomplished.
  • Since that same time (February 2011), Skype has been under order from the secret U.S. FISA court to not only supply information to the NSA, but also to make itself accessible as a source of data for the agency.  Whatever that exactly means is unclear, but it is likely not good for your privacy.
  • The NSA considers all use of encryption (except by them, I assume) a threat to their mission and it likely is.  If they cannot snoop, what use are they?  If people start using high quality encryption, they will make the snoop’s jobs that much harder.  But not impossible.
  • If you look in the dictionary for the word “packrat”, it will say, “see U.S. NSA”.  They horde data like you would not believe.  In fact, the rules that govern how long the NSA can keep data exclude encrypted data.  That they can keep forever.  So, if they ever figure out how to decrypt something, they can go back and look at the stuff that they have in inventory and figure out how much of that they can now decrypt and analyze.
  • In the leaked Snowden documents was a presentation from 2012 talking about NSA successes and failures regarding crypto.  Apparently, they categorize crypto into 5 levels from trivial to catastrophic.
  • Monitoring a document’s path through the Internet is considered trivial.
  • Recording Facebook chats is considered minor.
  • Decrypting mail sent via the Russian mail service Mail.ru is considered moderate.
  • The mail service Zoho and TOR are considered major problems (level 4).
  • Truecrypt also causes them major problems as does OTR, the encrypted IM protocol.  The Truecrypt project mysteriously shut down last year with no explanation.  Was it because the NSA was pressuring them?  No one knows or if they do, they are not talking.
  • It seems clear that open source software, while it probably contains as many weaknesses and bugs as closed source software, is much harder for organizations like the NSA to compromise because people CAN look at the source code.  Most people don’t have the skills, but there are enough geeks out there that obvious back doors in the code will likely be outed.  With Microsoft or Apple, that check and balance does not exist.
  • Things become catastrophic for the NSA at level 5.  The IM system CSpace and the VoIP protocol ZRTP (the Z stands for Phil Zimmerman for those of you who know of him) are or were level 5.  ZRTP is used by Redphone, an open source, encrypted, VoIP solution.
  • Apparently PGP, although it is 20 years old, also lands in the NSA’s category 5.
  • Cracking VPNs is also high on the NSA’s list. The Der Spiegel article doesn’t go into a lot of detail here other than to say that the NSA  has a lot of people working on it.  They were processing 1,000 VPN decrypt requests an hour in 2009 and expected to process 100,000 per hour by the end of 2011.  Their plan, according to Der Spiegel, was to be able to decrypt 20% of these  – i.e. 20,000 VPN connections per hour.  That was in 2011.  This is almost 2015.  You do the math.
  • The older VPN protocol PPTP is reported to be easy for them to crack while IPSEC seems to be harder.
  • SSL or it’s web nickname HTTPS is apparently no problem for them at all.  According to an NSA document, they planned to crack 10 million SSL connections a day by 2012.
  • Britian’s GCHQ has a database called FLYING PIG that catalogs SSL and TLS activity and produces weekly trend reports.  The number of cataloged SSL connections in FLYING PIG for just one week for the top 40 sites was in the billions.  This is a big database, apparently.
  • The NSA Claims that it can sometimes decrypt SSH sessions (I assume this is due to the user’s choice of bad cryptographic keys).  SSH is often used by admins to remotely access servers.
  • NSA participates in the standards processes to actively weaken cryptographic standards – even though this ultimately hurts U.S. businesses;  it also furthers the NSA’s mission.
  • The NSA steals cryptographic keys whenever possible.  Why do things the hard way when the simple way is an option.

While most hackers are not as smart or well funded as the NSA or the British GCHQ, sometimes luck is on their side.  Other, less friendly governments (think IRAN for example), might be willing to spend hundreds of millions of dollars to mess with the U.S. and since the don’t have to pay their scientists very much (the alternative to working for those governments might be being dead), their money likely goes further.

Would Iran or someone like them enjoy taking down the northeast power grid and darken the U.S from Boston to Virginia.  To quote a former vice presidential candidate – You betcha.  If they could damage the grid so that it took longer to get the lights back on (see the item from the other day on the attack on the German steel plant) would that be an extra benefit. You betcha.

So while I am using the NSA as an example, you could just as easily replace that with Iran, or Russia or China.

Being prepared is probably a good plan.