Sunday, January 8. 2017
CAcert is my favorite source of certificates. It has been that for years. The buggy Let's Encrypt I loathe, their poorly tinkered Python-scripts won't work and after couple hours of unnecessary fixing of their bugs, the scripts decide to write to my configurations. So, those guys really don't have a clue what they're doing.
However, CAcert isn't doing much better. Their root certificate is still MD5-signed. Argh!
CAcert's claim is, that "Severe weaknesses have been found in MD5, but at present they do not open vulnerabilities for X.509 certificates". But nobody else is buying that. It's just that this international non-profit organization is light on resources and they want to get his one done right. They just don't seem to be able to squeeze a re-signed root certificate out.
Briefly on certificate hashes
A X.509 certificate needs to be signed to make sure it originated from the Certification Authority announced in the certificate. Since the root certificates are typically self-signed, they are at the end of the certification chain, there is no other authority to validate them. That's why the hash of the signature is published at the CA's website. In case the hash doesn't match, it is possible to notice that somebody modified the signature.
What others are doing: Expiring MD5 and SHA-1 hash algorithms
Apple iOS, Oct 13, 2011, About the security content of iOS 5 Software Update
Microsoft, Aug 13, 2013, Update for deprecation of MD5 hashing algorithm for Microsoft root certificate program
On affected releases of Microsoft Windows, security update 2862973 requires that certificates no longer use the MD5 hashing algorithm. Microsoft products or third-party products that call into the CertGetCertificateChain function will no longer trust certificates that have MD5 hashes.
Microsoft, Nov 4 2015, SHA-1 Deprecation Update
We announced that Windows will block SHA-1 signed TLS certificates starting on January 1, 2017. In light of recent advances in attacks on the SHA-1 algorithm, we are now considering an accelerated timeline to deprecate SHA-1 signed TLS certificates as early as June 2016.
Google, Dec 31 2015, SHA-1 Deprecation: No Browser Left Behind
After December 31, 2015, SSL certificates that use the SHA-1 hash algorithm for their signature will be declared technology non grata on the modern Internet. .. over the course of 2016, will begin issuing warnings and eventually completely distrust connections to sites using SHA-1 signed certs.
Apple, Sep 20 2016, MacOS & Safari SHA-1 deprecation policy
Apple hasn't made any specific announcements here. The nearest we've come is a general warning in WWDC 2016 Session 706 What’s New in Security:
CAcert SHA-256 re-sign project
Altough CAcert guys think that there is no security flaw in MD5-signed certificates, they chose to do something about this. They managed to get the existing root certificate re-signed with SHA-2 on number of occasions. The most recent one is: root certificate re-signed. This was executed successfully on 2016-03-12
The result is kinda published, it's not publicly available, but if you're willing to go the SHA-256 project's SVN repository at http://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/outputs/, the result is available.
Go there! Get it! Use it!
Should I install the intermediate certificate too?
The idea with web server certificates is, that you establish trust to root certificate. All certificates are issued from intermediate-CA, which certificate can be revoked at any given time. That's why the intermediate certificate needs to be deployed with the server certificate. This is something many system admins keep misunderstanding.
Which keychain / store the CAcert root certificate should be installed?
My preference is always to install new root certs into system-wide keychain / store. That way any human users (me and possibly others) or system/daemon users get the new cert at once.
For this to work, you'll need
First disable trust to the old cert:
Remove the old cert by it's signature:
Add and trust the new cert:
The important point in macOS is to remember, that adding a root certificate to keychain doesn't make it trusted. You'll need to implicitly tell an added certificate, that you trust it too. That's kinda weird, but ... some smart guy at Apple designed that so.
For this to work, you'll need
Add and trust the new cert:
Ah, there are too many distros out there.
Any typical approach would be to place the file into
... This one I'll get back in a later post.
Thursday, December 8. 2016
The scammers are claiming, that they are missing my corporate VAT ID. Hm. That's strange. All the other information they got from Finnish Business Registry (ytj.fi). But as they are missing my valuable VAT-number, I'll need to fill it into a pre-filled form and add a binding signature. I'm not exactly sure, what exactly should I do with this form after signing it, but such a form was sent to me.
Caution! Scam here is in the monotype-font part (see above page 2):
Order: We hereby confirm the accuracy of our company' s data as per the information given above and we hereby place an order with DAD GmbH (Publisher) to publish them in a graphically highlighted form on www.e-b-n.eu according to the general terms and conditions printed overleaf.
We accept the advertisement' s annual costs of 890 Euro, which are payable in advance upon receipt of the invoice. We acknowledge that the contract is valid for the next three years and subsequently will be automatically extended annually unless we provide a written notice requesting termination of the contract, this being no later than three months before the expiration of the contract's term.
We are only able to revoke the contract by registered letter within fourteen days of the order date; whereby the date of postage is decisive. We authorize the Publisher to use contents found on our website for the layout of our insertion.
We acknowledge Hamburg-Mitte as place of performance and jurisdiction and that German law is solely applicable. We confirm that prior to this order placement we had no business relationship with the Publisher. We agree that our company's data will be stored electronically.
Whoa! That's a long and difficult to read. All that easier to miss the part with "We accept the advertisement' s annual costs of 890 Euro, which are payable in advance upon receipt of the invoice". Oh! I thought this was some kind of "final reminder", not an order nor invoice.
There is an actual website http://e-b-n.eu/ with all collected publicly available business information in it.
To make this scam more believable, scammers added actual addresses and phone numbers in Hamburg, Germany. I don't know if neither of them are legit. I do know, that German business registry doesn't have Commercial Register, Companies' Section, Hamburg Local Court, Record No. 88115 with name of European Business Register. Actually, that record number belongs to somebody completely innocent. Also the German VAT ID of 813739877 seems to belong to somebody, but I don't know how to do a lookup on German VAT IDs, so I don't know whose VAT ID it is.
By googling the VAT ID, I found pretty much the same letter sent to Italian doctors "Registro Italiano Medici: attenzione alla modulistica". There is a scanned PDF of the letter. Funnily, it has the same German VAT ID, and Mrs. Daniela Kunst as the managing director of EuroMedi (http://euromedi.eu/). The price is bit cheaper, only 877 €. Also the website is hosted in the exactly same IP-address in Köln, Germany. Also, there is Deutsche Internet Kartei and Internet Register Österreich with same VAT ID and managing director, but on a different server.
Based on a report by (Caution: European Central Register of VAT Registration Numbers is a scam) German law firm, this scam has been going on since 2013. So, looks like their business is lucrative and nobody seems to be able to stop them.
Wednesday, November 30. 2016
In the previous part we established that any certificate authority can issue a certificate to any website, even if the website admin doesn't want them to do that. This post is about technical measures attempting to monitor certificate authorities' actions.
Details that need to be addressed somehow
A certificate lifecycle is very simple. One is issued by a CA, it is used by a server and eventually it expires. When things go sideways, the server administrator may want to revoke an otherwise valid and good certificate, so there needs to be a mechanism to handle a single special case. So, two actions: issuance and revocation. Everything else is handled by itself.
To monitor certificate issuance and revocation, following requirements apply:
(This list is actually "borrowed" from certificate transparency tech comparison. Its just so comprehensive, so I had no other option than to use it.)
Certificate revoke list, aka. CRL
This is what we have since dawn of SSL. The idea is to go request the issuing CA and see if an already issued valid certificate is revoked. This information is published in a revocation list. The obvious problem is that revocation information doesn't happen instantly, and actually most browsers don't ever check a CRL.
To distribute the CRL-information, an issued certificate is supposed to have an URL to CRL (typically they do) and a client is supposed to be downloading that data periodically (typically they don't). In reality that doesn't work, as nobody wants to spend their precious time and bandwidth for downloading a ever-growing list of bad certs. To address that, there is a modern approach, Online Certificate Status Protocol or OCSP. It is supposed to be much faster operation with minimal bandwidth usage.
Neither of these really work well because of the need for an additional request. Also OCSP has a major fault, that a reply can be stored and "played back" on a query, so the reliability is more than questionable.
This is the newest one and it has a good chance of becoming the commonly accepted method for tracking certificate issuers' actions. There is an RFC 6962 defining Certificate Transparency and the source code is distributed as open-source allowing anybody to see how it works and do their own audit on it. Originally the project is initiated by Google, but number of CAs already accepted the technology including Symantec, Digicert. and Globalsign. One reason for wide adoption is, that Google (the author of Chrome browser), made an ultimatum, that the seriously expensive Extended Validation certificates need to have CT signature in them for Chrome to accept them as valid.
Internally CT works with a Merkle hash tree, something that BitCoin uses internally. So, it is safe to say, that this technolocy is a blockchain. Blockchain as a tech is quite new, but robust and reliable. The good thing about Certificate Transparency is, that this tech supports all requirements from above list. All a browser needs to do is periodically load the CT logs and during a connection, read the CT-signature from server's certificate, and based on that a browser can instantly verify or decline the server's certificate.
As mentioned, Certificate Transparency needs to be supported by your browser. Being a Google project, of course Chrome does support CT since version 35. Mozilla Firefox has announced support for CT, but at the time of writing there is no implementation yet. Microsoft doesn't support CT and they announced that that they're doing something of their own for IE11, naturally their new Edge browser doesn't support CT either. So that pretty much lands Chrome being the only browser really supporting this. The good thing is, that there exists many server-to-server monitors, for example Certificate Transparency Monitor.
Not accounting for poor browser support, another weakness CT has is that every certification authority has to include CT-signature in their issued certificates and publish their CT logs to general public.
DNS-based Authentication of Named Entities, or DANE is the first serious attempt to enforce certificate's ownership. The tech is described in RFC 6698 and multiple accompanying RFCs to clarify details of it's implementation. However, DANE hasn't received much public acceptance.
This is how Wikipedia defines DANE: "DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work."
As the above definition says, for DANE to work, a prerequisite is functioning DNSSEC. Nobody has that! Some stats at http://rick.eng.br/dnssecstat/ show that the situation is horrible. So, no DNSSEC, no DANE. Also DANE fails on two other things: additional requests are needed to DNS during connection and you need to trust the DNS-server response. DNS data can be forged or poisoned, so there's that.
Certificate pinning, or HTTP Public Key Pinning is an extension header of a HTTP-response. This is yet another Google-project, but its not widely adopoted. The idea for the web server to send public key information on every response, then the web browser is supposed to locally store the information for specified time. Then any subsequent responses from that same server are supposed to have the same information in them what was cached before. Weakness is that, the initial request needs to go to the real server. If your traffic was "man-in-the-middled" already at that point, you won't get any warnings.
Pinning is supported in Chrome and Firefox, but as Microsoft nor Apple support this, it is missing from IE, Edge and Safari. There is a funny mistake in Microsoft Edge's feature list as it states Firefox not supporting pinning, but Firefox was one of the early browsers supporting this feature.
Weaknesses here are, that it requires changes both on server and client sides. Also, when the certificate is legitimately changed, there really isn't a sensible mechanism to inform about that.
Collecting every web server certificate, aka that thing Google is doing
As you may remember from part 2 of this series, most of the rogue certificates issued are for Google services. So, they're fighting this by collecting all the certificates they see. They have a massive army of bots crawling web servers all the time. Google is also publishing their findings in a Certificate Transparency log for any interested parties to see. As mentioned before, there are publicly available non-Google services monitoring the CT-logs for abnormal changes.
This is very simple idea, if you see your certificate listed there, the certificate was issued by your request or somebody else's. It should be rather simple task to determine which one was it.
Anybody can use the human interface at Google Transparency Report site.
None of these technologies is really either useful, or widely adopted by major vendors. Fact remains: due to number of past incidents Certificate Authorities need to be monitored, supervised and publicly scrutineered. The best thing to attempt is to add some transparency to their actions. Which technology that would be is yet to be seend. What worries me is Apple's and Microsoft's total ignorance for this matter. I guess they'll need to be targeted first to wake up from their deep sleep.
Sunday, November 27. 2016
In the previous part we established the fact, that for HTTPS to work as intended, you as a web browser user need to trust your browser vendor's decision to trust the certificate authorities issuing the certificates to web server maintainers. This post is about when things go wrong, the chain-of-trust is broken and organization's actions are deemed not so trustworthy.
Known CA security incidents in chronological order:
As you already figured out the pattern. Anybody can issue any certificate for anybody. This many-to-many pattern isn't very trustworthy. Also, there seems to be more activity during the past two years or so, there is clearly more interest in gaining access to somebody's certificate.
In part 1 of my HTTPS-series it was established, that a X.509 certificate cannot identify the server. Now that cert-business sells certificates with a claim, that they have "verified" the request and the owner is who they claim to be, the above list tells another story. Nasty things happen when there is no verification, no real customer, but a malicious act of issuing a certificate for own cracking purposes.
Other acts of mistrust:
These acts are as evil, altough different by nature, but target the same thing: to gain access to your encypted data.
Ok, what's the risk here?
In practice, what is the threat here? What are those "nasty things" that can happen?
The incidents where new computers had a pre-installed trusted certificate, or your traffic was forced via man-in-the-middle -proxy are easier to address. Without you realizing it, all your encrypted traffic is directed to a party faking to be your intended target. Man-in-the-middle just de-crypts your passwords and credit card numbers and passes the traffic forward to the real target server acting as you. So, there is an obvious direct risk, that your traffic isn't secure at all.
Somebody issuing a trusted rogue Google certificate is bit more complex. A certificate itself isn't too dangerous, but in a scenario where the outgoing traffic from your computer is re-directed to a rogue server having the certificate you won't be able to tell the difference. How somebody's traffic can be redirected can be done locally, by changing your DNS-settings or remotely attacking the DNS-server your're using. Both cases are seen in real life. Nevertheless, it is almost impossible to know that such a change has been made and you go to a fake "google" server, enter your password without realizing, that somebody else is in possession of your login credentials. These cases haven't been publicly reported, but if anybody manages to pull that one off, it would be really really bad. Ultimately, there is only indirect risk, that you may lose your secure data.
Ok, this insecurity is horrible, isn't there anything we can do?
There are a number of technical innovations trying to govern the certificates. However, none of them are widespread nor commonly accepted. This leaves everybody at the mercy of certificate authorities and their actions.
I'll address those technical measures in my final part of this HTTPS-series.
This is the second part of a three part series addressing HTTPS and it's (in)security. Previous part was about basics of trusted certificates. Next part is about (failed) attempts to supervise if the trust is there or not.
Friday, November 25. 2016
Three years ago I was inspired by Scofield (or Mr. Harri Hursti) when he claimed that SSL is broken and it cannot be fixed. See the post for details. In reality tech can be fixed, my previous HTTPS-post is about shortcomings and fixes of TLS-encryption. This time I'm writing about another type of HTTPS-shortcoming, trust. This is between humans and is much much harder to fix.
Ok, most users don't see the difference between HTTP and HTTPS. They simply don't pay any attemtion if their address-bar has the lock in it or not. Those rare who do make the distinction between encrypted and non-encrypted web sites are blissfully ignorant about the inner workings of HTTPS. They don't understand the concept of a X.509 certificate nor the need for one. A certificate is needed to (I'm quoting Wikipedia article here) certify the ownership of a public key by the named subject of the certificate. The ownership of a key is important, it is used to make sure the communication parties are the same who initiated the connection. Without that, the security could be easily breached with a man-in-the-middle -attack.
What the certificate isn't designed is to identify nor verify the certificate holder. Technically, the certificate has a suitable field name subject. In HTTPS-certificate, it contains the hostname (or domainname in a wildcard certificate) of the server a secured connection is initiated to. If a certificate is used on a different server, the hostname used for connection and issued in the certificate won't match, and the lock won't "lock" or "go green" depending on your choice of a web browser.
The part where trust comes into play, is because the system is built so, that somebody issues the certificate. There is a chain of certificates to follow up to a root certificate to somebody who has authority to issue them. Any newly generated certificate is untrusted by your browser by default, unless the issuer root certificate is pre-added to your browser. That's where the certificate business (read: money) is. A certificate issuer has gone trough the hard work of pre-installing their certificate to all commonly used web browsers so that some website owner can come in and purchase a certificate from them and it will work and be trusted by any website visitors. What happens here is, you as the website visitor implicitly trust the website you are visiting, because somebody you don't know said they're who they announce themselves to be and they promised to be ok when asked about it. Of course browser and operating system companies play along with this, they do their due diligence and accept requests to distribute those root certificates to establish trust between the issuer and a website.
That's a bold request! Why should I trust somebody whose name is Verisign or Thawte or TeliaSonera, whom I know nothing about! No reason. But that's how security in Internet works.
This is the first part of a three part series addressing HTTPS and it's (in)security. Next part is about misappropriation of trust. Third part is about (failed) attempts to supervise trusted authorities.
Monday, November 21. 2016
This is a solution to my request #3 to Microsoft which I made in my post about Skype hack. Doing this will vastly improve your security for Skype-logins as the old Skype account and password cannot be used to login anymore.
Step 1: Merge Skype-account and Microsoft Account
For this sequence to work I have an existing Microsoft Account which is linked to my old Skype account. Also to state the obvious, I have different random password for every single service I ever use.
The message clearly states "Your old Skype password doesn't work anymore". A login with Microsoft Account password does work.
Step 2: Limit allowed login accounts
Un-check / check the ones to suit your login needs. I went for a single one, of course.
That's it. Done!
Saturday, November 19. 2016
This one won't fade away, so I'm taking a third swing at the subject. Previous posts are here and here. I've been actively following the conversation in Sype community's Security, Privacy, Trust and Safety board's discussion thread "Link to "baidu" website sent to all of my contacts".
Recap, what happened so far
Tons of fake links are being sent to people via Skype as chat messages. The chat is originating from somebody you already know and who is in your Skype's contact list.
Microsoft has stated "Some Skype customers have reported their accounts being used to send spam" when asked about it. That is true, people have been their Skype-accounts hacked by automated attacks based on leaked passwords and those accounts have been used to send crap to their contacts. However, this beef isn't about that. This beef is about the fact, that people whose Skype-accounts HAVE NOT been hacked, are sending crap to their contacts.
Microsoft went the classic way: "change your password". People did that. The same people are STILL sending crap to their contacts. For that, there is no official statement besides to (this is so ridiculous, I have to quote this verbatum) "Delete UNKNOWN Entry from
What people have also established, that there are two ways to login to a Skype session on any Skype-client. There is the old fashioned Skype-way and Microsoft Account. You can set a two-factor authentication into Microsoft Account, but not for Skype. Now that there are two ways to login, also please, remember that Skype can be run on multitude of mobile devices, Windows, Mac or directly from https://web.skype.com/. So, huge amount of attack surface exists there. What people have also established, that un-installing Skype from your device-of-choice doesn't make the problem go away, you'll still keep sending links to your contacts. So, reducing your personal attack-surface doesn't do it for you.
Obviously lots of people are royally pissed about this. Also Microsoft playing down their damage and offering completely useless support doesn't help.
The client devices are not compromized
When this kind of weird occurrence happens, any layman will immediately freak out and their mind there is with 100% certainity a single thought: my computer/phone has a virus!
In this case, no it does not.
People are "sending" these fake links after they un-installed Skype (two years ago). What exists, is the Skype-account. This is the hard part, which not-so-much-software-engineers don't grasp: your stuff in The Cloud can be cracked too, it doesn't have to be via your personal device. I don't know how to make this absolutely clear to a regular person.
The thing is: this issue is bothering many many people, and has been doing that since August 2016. All security flaw scenarios are possible, even cracked computers and mobile phones. However, that's not what interests me. My focus is on people whose computers have NOT been cracked, but are sending junk via Skype.
What's still happening
So, what's happened recenty is, that people are still receiving the links. Apparently (I haven't got any yet), the link has been changed from Baidu.com-based redirection to Vk.com, a Russian equivalent of Facebook. As I haven't received any of those, I cannot confirm the new link.
There are people, who have confirmed, that their Microsoft-account has been logged into from really weird geographic location. But that one can be easily fixed, change password and enable two factor auth they won't be doing that again. How the hack is actually done, we don't know. There was a theory about advertisement API, but personally I don't see that as a viable option. It would mean, that people actually would be using their Skype clients, but there are tons of people who haven't done that for couple years and are still spewing crap around.
Do something about it: Check that your account isn't cracked
What I'd like to see is what newly created Skype-accounts have and make the original Skype-account be gone. As in merge/delete/drop. I don't need two separate logins for my Skype. Especially as there is no 2-FA, or login device history for it.
This is what you can do is make sure your Microsoft Account is secure. Login to https://account.microsoft.com/.
I've redacted the IP-address from Belarus. It's most likely some poor bastard's machine, which is cracked and used as a springboard forward.
What I'd like to see happen
Firstly Microsoft, the owners of Skype need to step forward and confirm that accounts with proper passwords are being used to send crap. They need to admit, that their systems are not recognizing any accepted password logins, but chat messages are still being sent by innocent people.
Secondly, they need to fix the issue. Whichever is broken there they need to address it. The worst case scenario is, that somebody can actually inject new chat messages out of thin air, without the sender being logged in.
Third, the old skype account login needs to be secured. That's the easiest one here to achieve. As newly created Skype-accounts are only via Microsoft Account, that shouldn't be much problem. Also I'd like to get rid of that login method. Update: Instructions for doing this are in my next post.
So, Microsoft, we're waiting for you.
Monday, November 14. 2016
On Friday 11th November, I got yet another Baidu-link from one of the same contacts, I've already received some.
As I've been communicating with the persons who are "sending" me these links, they have changed their Skype-password for their old logins since this incident gained publicity. At this point, I'm ready to bet serious money on the fact, that this is not what Microsoft officals state, a case of re-using leaked passwords. This is a serious incident with protocol having a security flaw which is being exploited by somebody who loves pointing a finger to Baidu. As the link-jumping ends at a fake Forbes site with a fake article about a miracle pill allowing you to access 100% of your brain, I don't think Chinese have anything to do with this case. IMHO this points to Russia based on the fact, that this link rotator is located in a .ru-domain and is located in St. Petersburg, Russia.
This is how the fake Baidu-link redirects your request:
Wednesday, November 9. 2016
For the past couple of days, I've been getting weird Baidu links via Skype chat. The sender is somebody I actually know and is my contact. The messages do not stay in the message history for that person, nor they never received the reply I sent back when the link was received. It's really weird to receive such links to a Chinese search engine in the first place, but the elusive chat history is the definite clue: somebody hacked Skype's protocol. Also, I find it strange, that the link contains my Skype-handle in it (obfuscated in below pic).
I'm not alone with this phenomenon: Link to "baidu" website sent to all of my contacts.
As the messages I got are from actual contacts, I followed up on them. Both persons deny sending me such links, and their message history doesn't display the link either. So, I don't think that the personal accounts are cracked, it's the Skype servers that are being exploited. Hopefully Microsoft-guys figure this out and plug the hole.
Couple hours after posting this, somebody posted a link to Why are Skype accounts getting hacked so easily? into Skype's community discussion. The article makes a claim that Skype's 2-factor authentication can be circumvented easily by using the old Skype credentials. Looks like you can still log in with Microsoft-account (pretty secure) or the credentials used before Microsoft acquired Skype. The old credentials cannot have 2-FA set up into it and most likely you already forgot it even exists. That seems to be the way how nasty people make their way in.
Update 10th Nov 2016:
Recent buzz is about a similar incident last year, when users' Skype accounts were used to send spam. So, nobody has come forward with any proof that the protocol would be compromised. It is gearing towards to the fact that users didn't realize there are two separate passwords to their Skype account, and the non Microsoft-account had a weak password which was used to gain access to contact lists.
Update 14th Nov 2016:
Monday, October 17. 2016
Arstechnica wrote last week: NSA could put undetectable “trapdoors” in millions of crypto keys. The article in the link says:
So, there is a mathematical weakness in DH-key exchange algorithm when using 1024 bits and suitable prime number.
It so happens, that Diffie Hellman has been taking major hits in the past. In May 2015 team of researches found out an implementation failure in DH-key exchange called Logjam Attack. There is no mathematical weakness, but when negotiating a key exchange, client forces the number of bits used to be ridiculously low instead of server's suggestion. And in their discovery they suggested:
All this means, that the entire Diffie Hellman algoritm is riddled by different types of flaws and any reliability it previously enjoyed among security community is gone. Even with a Logjam-patched server, using less than 1024 has been insane for a long time. Now 1024 bits are gone, what next?
In practice this affects HTTPS, SSH and VPN-tunnels. Ok, there are other software using DH-key exchange, but I'll try to keep this simple.
So, there is no backdoor that NSA or anybody can open. It's just that when client and server agree on details of the encryption used in communication, the encryption key used can be calculated by a listening party. If somebody cannot capture your key exchange and encrypted bits, they cannot de-crypt the communication. However, if somebody can grab your bits and either you're using too weak DH-key exchange, or somebody can tamper the connection and do a "Logjam", then your connection's security will be impaired. The best option is to use some other protocol for key exchange.
There is more information about key exchange and Diffie Hellman in my previous article TLS Security recap - HTTPS (in)security up until 2016.
Diffie Hellman in TLS (SSL)
To quote the Wikipedia article about Diffie Hellman: "There are three versions of Diffie Hellman used in SSL/TLS: Anonymous Diffie Hellman, Fixed Diffie Hellman and Ephemeral Diffie Hellman". To make things confusing, there is also Elliptic curve Diffie–Hellman (ECDHE), which is not affected. For the purpose of this article, it is considered a completely another key exchange protocol. Yes, it has Diffie Hellman in the name, but ... still not affected.
Of those four protocols, pretty much the only ones being used in today's Internet are DHE (affected) and ECDHE (not affected). When looking at stats according to SSL Pulse, Survey of the SSL Implementation of the Most Popular Web Sites, only 27% of the sites tested supported DH/DHE with 1024 or less bits.
What you can do
The simple version is: nothing.
The string "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", means, that the TLS 1.2 connection is using elliptic-curves DHE (the not affected one) for key exchange.
If you want to make things really interesting, from a Linux command prompt try to lure the server to use DHE as key exchange method. First get a list of suitable ciphers:
Let's pick one with weak key exchange, but with powerful crypto DHE-RSA-AES256-GCM-SHA384, and go for it:
As guys at Google are smart, they won't allow that. What you have is "CONNECTED" and "alert handshake failure". It means, that your client and their server failed to agree on suitable cipher suite to use. Your request for using DHE was the key here.
If you are a server admin and didn't stop accepting Diffie Hellman as key exchange before this, do it now.
If you are a regular internet user, don't worry number of government-level organizations already have your data!
Monday, September 12. 2016
Every once in a while I have enough time to read books. The ones made out of paper having printed words and images on the paper. And pretty much 98% of the books I've read in the last couple of decades have something to do with my profession. There is one book, that's worth mentioning: Security Engineering by Ross Anderson.
The price point for getting this one is a non-issue, you can download the entire book as a PDF with no cost at http://www.cl.cam.ac.uk/~rja14/book.html (that's at University of Cambridge). Having the book available is fully intentional, as four years have passed, author and publisher have agreed to place the material freely available for anybody interested. I most sincerely thank Mr. Anderson of doing that.
Of yourse, I recommend you to support this good work and purchase one. Go to Amazon, or similar and get your own copy. It will include a digital copy, all you have to do is go to above link and download one.
I'd definitely recommend this book to anybody ever designing or implementing anything with a computer. As the phrase goes: “Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.” This is your chance of getting ahead and learning how some smart people blundered in their design and/or implementation of security. There is so much information in the book, but I found the case studies being the best part. The general idea is to get an injection of experience and start to think like hackers do.
My recommendation is that, for anybody working in software engineering should memorize this book and have an exam taken, so that it is crystal clear how secure systems are done.
Thursday, April 28. 2016
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:
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.
Wednesday, April 27. 2016
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:
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.
Friday, April 22. 2016
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.
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.
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).
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"".
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.
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!
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!
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.
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:
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:
The line of 4 NULLs reads: no key exchange, no authentication, no bulk ciphering and no message authentication
Last one in the list is:
That reads: RSA key exchange, pre-shared-key authentication, ChaCha20 Poly1305 bulk cipher, with SHA-256 message authentication
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?
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!
Thursday, February 25. 2016
My honeypots draw in all kinds of waste. Lately I've been getting lot of "invoices", Russian Rolex resellers and ball bearing ads from China along with the usual crap. I keep combing trough all that muck in case there are hidden pearls among them. Today there was.
So, here goes the story from beginning. I got his e-mail from Ukraine:
Last time it was from "American Airlines", my tickets were in the e-mail. See details of that scam here.
The interesting part of that "IRS" tax refund e-mail was the attachment. It was a .zip-file containing a single file named
That's completely obfuscated crap. When beautified, it's still obfuscated crap:
The good parts are what
What every developer notices instantly is, that you cannot expect to use WScript in your code, unless you're running Internet Explorer or Edge as your browser. Still, that just limits possible victims. Most likely to just those ones who don't understand not to open the attachment.
There were three innocent sites around the net where the payload was loaded. It got all of them to confirm. Now that I had all the moving parts, I went to F-Secure website to submit my findings. The address is: https://www.f-secure.com/en/web/labs_global/submit-a-sample
They analyzed my findings and added it to their malware fingerprint database. I checked their most recent threats-list, and yes! I made it. There it was:
Lot of nasty and wily stuff floating around in the net. Be careful out there!
(Page 1 of 3, totaling 43 entries) » next page
RSS feeds of this Blog