ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

What is DigiNotar, SSL, Security Breach, and how does it affect you? What did get hacked? Now what?

Updated on April 6, 2013
https, secure HTTP browser through SSL encryption
https, secure HTTP browser through SSL encryption

Introduction

You may have heard about tech news reporting some Dutch security firm got hacked and in response, many web browsers are getting updated to fix this breach. You may have wondered, how can something in Netherlands affect your browser?

What actually happened is a Dutch company, called DigiNotar, who is a "certificate authority", got hacked, and many fraudulent certificates have been issued. These fraudulent certificates can allow the holders to impersonate well-known websites and thus intercept traffic, even though the user thought the traffic is encrypted. In other words, it is a method of eavesdropping and potentially much worse. And this affects everybody because the certificates are used by everybody, even if you don't recognize it.

How did it happen, how does it affect you, and what can you do about it?

How a Browser Communicates Securely

A web browser normally sends and receives data without any security or encryption. It is not worth the effort, as most text is innocuous. However, when it comes to important things like passwords, credit card numbers, purchases, and so on, security is required, as the browser needs to talk to the server without any chance of someone intercepting the data. Thus is born Secure Socket Layer, or SSL.

You may recognize SSL by a "lock and key" symbol displayed by the browser next to the URL or in the status bar.

The way SSL works is as follows:

  1. Browser to server: Prove who you really are, show me your ID certificate
  2. Server responds: here's my ID certificate, check it yourself
  3. Browser checks the ID certificate against its "white list", stop if not acceptable
  4. Browser to server: I accept your certificate, prepare to start encryption on my mark
  5. Server responds: ready when you are
  6. Browser then starts communicating securely to the server

How the data is encrypted is not that important. SSL use a 128-bit encryption.

This requires the certificates to be trusted. If you can't trust the certificates, then the whole system collapses. Much like airport security checking individual IDs, if you can't rust the ID, then nobody will be able to fly.

Where do these certificates come from?

These SSL certificates are issued by "certificate authorities" which are companies who now only issue SSL certificates, but also help browsers verify certificates. The process is as follows:

  1. Browser to server: Prove who you say you are, show me your certificate
  2. Server: here you go, here's my certificate
  3. Browser: hmmm... I don't recognize this certificate, it's not in my white list
  4. Browser: this certificate says I can go to this specific certificate authority to verify it. I do recognize this certificate authority to be valid.
  5. Browser to certificate authority server: I got this certificate here says it's issued by you. Is it real?
  6. Certificate authority server: Yeah, it's real
  7. Browser: okay, I'll add this certificate to my 'white list'
  8. Browser to server: your ID is confirmed, prepare to start secure channel comm...

Each browser is configured to accept only specific "certificate authorities" in the world. After all, you can't just let anybody claiming to be one. This is encrypted and a part of the browser itself.

Why a Certificate Authority Hack is VERY bad

DigiNotar, a dutch certificate authority, was hacked, apparently by one or more Iranian hackers, and its server was breached, and unknown number of certificates were issued fraudulently to big names, like Google.com and so on. With such fraudulent certificates, and access to the right hardware, holder of such certificate can intercept and decrypt secure traffic that the user thought to be secure. This is how it would work:

  1. Browser to server: I want to communicate securely, show me your ID
  2. Fake server responds: here's my ID (fake)
  3. Browser: I don't recognize this ID, but the certificate authority seems valid...
  4. Browser to certificate authority server: Did you issue this ID?
  5. Certificate authority server: looks valid to me
  6. Browser goes back to the "fake" server: okay, start secure comm when you're ready...

Now you probably ask, WHY would ANYBODY communicate with a fake server? The answer is... when they don't realize it's fake, and real traffic was diverted. This is due to the way browser, and the Internet in general, works.

How DNS works, and how you can be hacked without knowing

Most people don't know what goes behind the scenes when a browser does its stuff, thus most people don't realize the possibilities of compromise. When you type in an URL, the following actually happens:

  1. Browser takes the "domain name" (i.e. Google.com), and sends the name to "Domain Name Service" (DNS) server.
  2. The DNS server responds: This domain name is at IP address xxx.xxx.xxx.xxx (actual number does not matter)
  3. Browser then sends traffic to that IP address, NOT THE NAME.

The DNS server is usually ran by the your internet service provider (ISP), who copies it from THEIR provider, and so on until the traffic goes to the "root" DNS server. However, It is possible for someone to install a FAKE DNS server, and redirect the traffic meant for Google.com to some other IP address. Existing DNS server can also be hacked to redirect traffic.

Thus, someone trying to access Gmail securely can then be tricked:

  1. User to browser: go to Gmail.com
  2. Browser to DNS server: give me IP address of Gmail.com
  3. DNS server spat back some OTHER IP address, NOT of Gmail.com
  4. Browser goes to this pseudo-gmail server: show me your ID certificate
  5. Pseudo-gmail server: here you go (shows fake ID)
  6. Browser: I don't recognize this ID, but the certificate authority seems valid, let's check
  7. Browser to certificate authority: did you issue this ID?
  8. Certificate authority: looks valid to me
  9. Browser to pseudo-gmail server: okay, you look authentic enough. Prepare to start secure communications
  10. Pseudo-gmail server gets the traffic, logs it, then forwards it to the REAL gmail.com... or it can pop up a fake error page, do "please try again", and send the user to the real gmail.com, AFTER having logged their username and password.

The user would have never noticed a thing!

This is known in the security circle is "Man-In-The-Middle" (MITM) attack, where the hacker managed to get in the middle of the traffic chain and pretend to be the endpoint.

How Was the Hack Discovered?

On August 28, 2011, an Iranian user was surprised to see a warning pop up when he tried to go to GMail. Chrome has detected that someone is claiming to be Google.com (which is in the US), but the SSL certificate came from DigiNotar, which is in Europe, and that was enough to raise a warning. He posted the possible breach on Google Help, and it was quickly confirmed by Google (within 24 hours?) as a MITM attack aimed specifically at Google and Gmail.

How did Chrome detect the hack? Google's Chrome / Chromium browser has a security feature since June 2011, that detects certificate abuse through "certificate pinning". It does this by adding logic that denotes which certificate authority has the responsibility for certain locations. For example, a European certificate authority should not be able to issue certificates for domains in Africa or Americas, and vice versa.

Microsoft issued a patch and security update on August 29th to deal with this problem. Mozilla issued a security patch on August 30, 2011 to seal off this breach (and blacklisted most of DigiNotar's certificates). On September 6th, Mozilla issued another update that blacklisted ALL of DigiNotar's certificates, essentially ending DigiNotar's "certificate authority" status.

Who Was Affected? Who Did it?

Who would go to such trouble to hack DNS servers AND certificate authority servers just to get passwords and so on? The major suspects would be... the Iranian government. Google itself warned ALL Iranian users of such a breach, really. In fact, this breach supposedly happened in July 2011, and was not discovered until AUGUST 29, 2011, when Dutch authorities ordered DigiNotar to revoke various certificates it judged to be fraudulent. This was then discovered by some Iranian users, and the news quickly spread from there. Dutch government had used DigiNotar certificates in many of its government websites and as a result is severely embarrassed by this security breach. it had publicly stated that security of its government websites and linked databases can no longer be trusted. It had taken over the company and brought in experts to determine how bad the situation is.

Google believe the hack currently only affected about 300000 users of Gmail, mostly from Iran. Traceroute logs posted by Iranian users show extra suspicious hops within Iran when accessing Google related domains, but not with other domains.

Dutch authorities then revealed that audit of DigiNotar's servers shows that HUNDREDS of certificates were issued fraudulently by the hacker for domain names that included the CIA, Mossad (Israeli intelligence agency), government websites, as well as who's who on the Internet, and some certificates have been completely lost. They don't really know what is the extent of this breach, in other words, other than it is completely devastating. In fact, Dutch government also revealed that the breach may have happened in June 2011, but the Dutch government was NOT immediately informed. This made ALL DigiNotar certificates untrustworthy. Over 55000 certificates from DigiNotar were used in Netherlands alone, many by government sites. DigiNotar certificates were also used as PersonalID, and that is now also untrustworthy.

The same hacker that got DigiNotar is believe to be the same hacker that attacked Comodo, another certificate authority, in the US, in early 2011. He now goes by the hackername "Comodohacker". That breach was limited and only a few certificates were issued fraudulently, and quickly revoked. Still, it set a dangerous precedent. And he claimed he can do much much more.

In the wake of this widespread "panic" after the DigiNotar breach was exposed, mistakes and misinformation quickly spread. Symantec, a computer security firm, had to dispel several rumors when the Dutch government accidentally claimed that another Certificate authority, Thawte, had been breached.

What Can You Do?

What should you do if you may be affected?

First, update your browser AND Internet related software ASAP. Apple have released update for OS X that patches this vulnerability, and all major browser makers have updated their browsers as well. Update ASAP.

Second, change ALL your passwords, ASAP, AFTER you update the browser.

Third, clear cookies and log out of EVERY online session, then log back in using the new password.

Fourth, READ every warning that came from your browser.


Conclusion

The DigiNotar "mess" is widespread and affects far more people than most expect. By attacking something in the background, this hack is rather insidious and raises doubt on the entire SSL protocol and how it secures what we do on the net.

While so far only effects are seen in and around Iran, there's no telling what sort of damage a more concerted attack can do. Some security experts have proposed various additions to SSL, such as DNS security (verify DNS) as well as Convergence which "crowd-sources" the certificate by comparing each other's certificate with each other, to spot differences, and thus, the "odd man out", if there is a man-in-the-middle attack. Unfortunately, such methods so far are rather untested.

Still, security experts are working on it, and I hope you have learned a bit about it.

working

This website uses cookies

As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://corp.maven.io/privacy-policy

Show Details
Necessary
HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
LoginThis is necessary to sign in to the HubPages Service.
Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
AkismetThis is used to detect comment spam. (Privacy Policy)
HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
Features
Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
MavenThis supports the Maven widget and search functionality. (Privacy Policy)
Marketing
Google AdSenseThis is an ad network. (Privacy Policy)
Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
Index ExchangeThis is an ad network. (Privacy Policy)
SovrnThis is an ad network. (Privacy Policy)
Facebook AdsThis is an ad network. (Privacy Policy)
Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
AppNexusThis is an ad network. (Privacy Policy)
OpenxThis is an ad network. (Privacy Policy)
Rubicon ProjectThis is an ad network. (Privacy Policy)
TripleLiftThis is an ad network. (Privacy Policy)
Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
Statistics
Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
ClickscoThis is a data management platform studying reader behavior (Privacy Policy)