What's wrong with HTTPS: Part 2 - Untrustworthy Certificate Authorities
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:
- 2010 (multiple incidents): Key Internet operator VeriSign hit by hackers
- There isn't much information available on this, but they disclosed this on their quarterly report.
- "Are we finally ready to accept that the certificate system is completely broken?"
- Bruce Schneier, on his blog
- March 2011: Hackers target Google, Skype with rogue SSL certificates
- Comodo was cracked, and certificates for orgs like Google were issued without them knowing about it.
- August 2011: Hackers stole Google SSL certificate, Dutch firm admits
- DigiNotar was cracked and Google certificates were created. Later DigiNotar went bankcrupt as they reputation was gone.
- December 2013: French Government ANSSI responsible of a MITM against Google SSL-TLS
- French CA issuing Google certificates
- July 2014: Indian government agency issues fake Google certificates
- This is really bad! A government agency in India issuing Google certificates. I'd understand a company doing that, but government... no.
- December 2014: Turkish Certificate Authority screwup leads to attempted Google impersonation
- Turkish CA issuing Google certificates
- March 2015: Google to drop China’s CNNIC Root Certificate Authority after trust breach
- A Chinese CA issuing Google certificates.
- September 2015: Symantec employees fired for issuing rogue HTTPS certificate for Google
- Inside job at Symantec, guys wanted to issue Google certificates
- October 2016: Distrusting New WoSign and StartCom Certificates (on Mozilla and on Google)
- WoSign issued certificate for GitHub, yet another inside job.
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:
- January 2015: Gogo Inflight Internet serves up 'man-in-the-middle' with fake SSL
- Inflight service provider goes man-in-the-middle on purpose. Of course all bad deeds can be wrapped into good intentions, they wanted to "protect the bandwidth usage".
- February 2015: Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections
- Lenovo laptops were pre-installed with a certificate used for snooping your HTTPS-traffic. The thing is: if anybody can inject a trusted root certificate to your computer, you won't notice that somebody is reading your encrypted traffic.
- November 2015: Dell does a Superfish, ships PCs with easily cloneable root certificates
- Yet another pre-installed certificate making man-in-the-middle. Every computer had same PKI installed making anybody able to eavesdrop your carefully encrypted traffic.
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?
Yes.
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.
What's wrong with HTTPS: Part 1 - Trust issues
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.
Removing old Skype-login and going for Microsoft Account
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.
Go to https://account.microsoft.com/.
Login there with your Skype-account.
This is important! You need to use the old Skype-account for logging in.
Merge the accounts:
Yes! Single password login:
Testing:
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
Yet again, go to your Microsoft Account. See More security settings:
In there, you'll find Change sign-in preferences:
Now you see a list of possible logins to use:
Un-check / check the ones to suit your login needs. I went for a single one, of course.
That's it. Done!
Now your Skype login security is vastly improved.
Skype protocol hacked, part 3
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 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run and Delete all UNKNOWN files under %appdata%\Roaming". Link to the exact instructions is here. So, I consider myself to be well educated about finer details what's inside Windows registry or Windows user profile. Because there are thousands of entries there, I don't know all of them, it is impossible to tell which of them are unknown and which are not. How would somebody with almost no experience be able to do that! 
Actually the magnitude of Microsoft support blunder is so huge, they wiped off the chat log from the discussion board and Box.com.
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
There is no login-history, device list or anything that would resemble modern tools to audit your own account in the traditional Skype. This is what you can see:
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/.
So, nothing wrong with my account. Here is an account having more-than-dubious history entry in it:
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.
Skype protocol hacked, part 2
Monday, November 14. 2016
Windows 10 update KB3200970 stuck
Thursday, November 10. 2016
Hands down KB3200970 is the worst update I've seen for Windows 10!
In general I hate Windows 10 TiWorker-process. It sucks CPU like there is no tomorrow. I cannot comprehend how difficult it is to determine if an update is needed or not. If you compare to any Linux .deb or .rpm packaging, a simple update check in Windows 10 is way too heavy. I find this kind weird. When Microsoft announced simplifying servicing models for Windows 7 and Windows 8.1, the reasons were to reduce scan times and finding right patches easier. It certainly doesn't feel like it to me.
So, there is Cumulative update for Windows 10 Version 1607 and Windows Server 2016, released November 8, 2016. This is also known as KB3200970 and boy, do people have trouble installing it!
This is what happened to me:
For about 8 hours it was stuck there in the preparing phase. While doing absolutely nothing, this was my CPU-load:
Well done idiots!
Net is full of stories like mine: How to fix Windows Update in Windows 10 if it becomes stuck, Windows 10 KB3200970 issues: install fails, high CPU usage, battery drain and more and Cumulative Update for Windows 10 Version 1607 for x64-based Systems(KB3200970).
The Reddit-article had a link to KB971058, How do I reset Windows Update components? which helped some. I gave it a try and it did help.
First some services needed stopping. This is what you would run as an administrator cmd.exe:
net stop bits
net stop wuauserv
net stop appidsvc
net stop cryptsvc
In my case the wuauserv didn't stop, I had to find the process id for it and kill it manually. After all that, I attempted renaming:
Ren %systemroot%\SoftwareDistribution SoftwareDistribution.bak
Ren %systemroot%\system32\catroot2 catroot2.bak
First one failed, so I don't know what the impact was. Then I ran the entire list:
cd /d %windir%\system32
regsvr32.exe atl.dll
regsvr32.exe urlmon.dll
regsvr32.exe mshtml.dll
regsvr32.exe shdocvw.dll
regsvr32.exe browseui.dll
regsvr32.exe jscript.dll
regsvr32.exe vbscript.dll
regsvr32.exe scrrun.dll
regsvr32.exe msxml.dll
regsvr32.exe msxml3.dll
regsvr32.exe msxml6.dll
regsvr32.exe actxprxy.dll
regsvr32.exe softpub.dll
regsvr32.exe wintrust.dll
regsvr32.exe dssenh.dll
regsvr32.exe rsaenh.dll
regsvr32.exe gpkcsp.dll
regsvr32.exe sccbase.dll
regsvr32.exe slbcsp.dll
regsvr32.exe cryptdlg.dll
regsvr32.exe oleaut32.dll
regsvr32.exe ole32.dll
regsvr32.exe shell32.dll
regsvr32.exe initpki.dll
regsvr32.exe wuapi.dll
regsvr32.exe wuaueng.dll
regsvr32.exe wuaueng1.dll
regsvr32.exe wucltui.dll
regsvr32.exe wups.dll
regsvr32.exe wups2.dll
regsvr32.exe wuweb.dll
regsvr32.exe qmgr.dll
regsvr32.exe qmgrprxy.dll
regsvr32.exe wucltux.dll
regsvr32.exe muweb.dll
regsvr32.exe wuwebv.dll
Lot of them failed, but that's what the KB971058 told to do. Then starting the services:
net start bits
net start wuauserv
net start appidsvc
net start cryptsvc
Still this update tested my patience. It ran couple hours preparing after it announced, it's ready to go install. The installation took yet another couple hours. After the installation was completed and the obligatory reboot was done, Windows still reported that a reboot is required. This update really sucks ass!
Ultimately my laptop spent more than 50 hours to install all this. There were number of retrys and times than I didn't care to look to closely what's going on, so the machine had to wait for user interaction. Still the process was paintakingly long.
Skype protocol hacked
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).
The message looks like this:
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.
Update:
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:
Confirmed, that this is not a case of using leaked passwords, my second post about this is here.
Happy Halloween!
Monday, October 31. 2016
Those of you, who celebrate All Hallows' Eve today: have a happy one!
I whipped up my pumpkin knife and carved a very scary(?) looking one for those kids ringing my doorbell for trick or treating.
Update:
This iFixit teardown of a pumpkin isn't how I did it.
Why is there no real commitment for IPv6?
Saturday, October 29. 2016
I've been an active IPv6-user for many many years. Of course my ISP doesn't offer a native IPv6, so I'm using a tunnel from SixXS. They have been providing such tunnels free-of-charge for years, and for that I thank them and the ISPs volunteering their capacity for us nerds to have decent IPv6-connectivity. SixXS got tired for IPv6 not getting any traction, the ISPs have almost zero commitment for allowing people to use real, native IPv6. SixXS has a campaign called "Call Your ISP for IPv6!", but I don't think that's going to make much of an impact. When any ISP is actually asked about their IPv6 support, they'll stall by "we'll announce it later" or "but we do support IPv6" (by some unusable mechanism).
When looking what's happening on the ISP-side, Telia (or Sonera, as we call it here in Finland) has enabled 6rd for their connections. It combines DHCPv4 by returning enough parameters for an IPv6 setup with a 64-bitmask to be done. It kinda works, but ... still not the real thing I'm after. Also Elisa and DNA, two big mobile telcos in Finland, started offering IPv6 (DNA, Elisa) for their customers, but ... I'm not going to change my home fiber for a mobile connection. So something is happening at the telco-scene. I'm just waiting my ISP (Elisa) to act on the wired side too.
The other side of the chicken-egg -problem are the services. There is no real commitment on their side either. For example Amazon AWS (a really huge infrastructure provider) really doesn't support IPv6, they have nice IPv6 support for Internet-facing load-balancers, their S3 storage and their content delivery net Cloudfront, to mention few. But when it comes to running a server instance with real native IPv6, no dice. So, you can market your service to be IPv6-ready, all the critical Internet-facing services really do support IPv6, but your infra runs on IPv4 private addresses. Not cool.
And when it comes to services, this is a typical scenario:
That's what's been happening for LinkedIn for I-don't-know-how long. At least this week.
Me being the nerd I am, some background investigation:
# telnet www.linkedin.com 80
Trying 2620:109:c007:102::5be1:f881...
telnet: connect to address 2620:109:c007:102::5be1:f881:
Connection timed out Trying 91.225.248.129...
Connected to www.linkedin.com.
Escape character is '^]'.
A classic.
Their IPv6 is down and they don't know about it. This is their level of commitment:
On September 2014, they announce to have done a "Permanent launch of IPv6". But none of them are using it themselves to realize it has been down for a week! The really scary thing is, that they cannot afford $10 a month for a Pingdom check. 
That's what I recommend for everybody to use for monitoring on-line services. Any reputable admin needs to know the second a service is out of reach by general public. IMHO that should include also admins at LinkedIn.
When it comes to lack of IPv6, I need to come clean. This blog isn't running on IPv6 either. Since most of you don't have it, it is impossible for you to know. My co-location host cannot offer me the IPv6, so no avail.
But why? Why is there no real commitment for IPv6? What's blocking all sensible people for going all-in IPv6? Everybody knows, that all possible IPv4 addresses were allocated by IANA to telcos and ISPs in January 2011. So, there is no more. Of course there are plenty of available addresses in RIRs to allocate for regional telcos, so we're not completely bankrupt with IPv4-addresses. But that day is eventually coming, it's just a waiting game. Notable efforts like World IPv6 Launch Day yield no mentionable results.
So what's holding us back? I don't know anything else except everybody going on the path-of-least-resistance. Since there are available IPv4-addresses, why risk a change. With change things can go broken or something may shift so that some people will lose some and others will win some. Not that much of a risk, if you ask me. But here we are, inching towards IPv6 very slowly. Speed it up, goddamnit!
Diffie Hellman key exchange (1024 bit) unreliable
Monday, October 17. 2016
Arstechnica wrote last week: NSA could put undetectable “trapdoors” in millions of crypto keys. The article in the link says:
A special prime devised by the researchers, however, contains certain invisible properties that make the secret parameters unusually susceptible to discovery. The researchers were able to break one of these weakened 1,024-bit primes in slightly more than two months using an academic computing cluster of 2,000 to 3,000 CPUs.
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:
The Logjam researchers include some talk about how some "attackers with nation-state resources" could break through 1024-bit DH.
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?
Impact
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.
If you really want to, you can check which cipher suite your browser is using:
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:
# openssl ciphers | perl -ne 'print join("\n", grep {/DHE-/} split(/:/));'
Let's pick one with weak key exchange, but with powerful crypto DHE-RSA-AES256-GCM-SHA384, and go for it:
# openssl s_client -cipher 'DHE-RSA-AES256-GCM-SHA384' -connect www.google.com:443
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.
Final words
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!
macOS Sierra upgrade from USB-stick
Friday, October 14. 2016
This is the abridged version as most steps are exactly like in OS X El Capitan. See my article about that.
Step 1: Go download
As any upgrade, go to App Store, it should look like this:
Beware, it is quite a chunk (almost 5 GiB to be exact). If your Internet connection isn't too fast, be prepared to wait a while:
When the download is done, the installer will start automatically. It will look like this:
That's your cue. Do not proceed with the installation, but quit the installer instead:
Now all the necessary files are on your machine.
Step 2: Go USB
The recipe is classic, insert an USB-stick of suitable size, unmount it, prepare it for install, copy installation files to it and you're done!
Unmount (your volume name will differ, unless the stick had an Arch Linux installation in it):
sudo diskutil umount /Volumes/ARCH_201607/
Pay attention to the output, it will give a clue about the device identifier of your USB-stick on your machine it can and will vary. My output was:
Volume ARCH_201607 on disk3s1 unmounted
Now that we know which disk it was, partition and format the stick as JHFS+:
sudo diskutil partitionDisk /dev/disk3 1 GPT jhfs+ "MacOS Sierra" 0b
It will take a while and during operation it will say something like this:
Started partitioning on disk3
Unmounting disk
Creating the partition map
Waiting for the disks to reappear
Formatting disk3s2 as Mac OS Extended (Journaled) with name MacOS Sierra
Initialized /dev/rdisk3s2 as a 7 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Finished partitioning on disk3
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *8.0 GB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_HFS MacOS Sierra 7.7 GB disk3s2
Now the stick is good to go, transfer the installation image into it:
cd /Applications/Install\ macOS\ Sierra.app/Contents/Resources/
sudo ./createinstallmedia \
--volume /Volumes/MacOS\ Sierra/ \
--applicationpath /Applications/Install\ macOS\ Sierra.app/ \
--nointeraction
Again, that will take a while and output something like:
Erasing Disk: 0%... 10%... 20%... 30%...100%...
Copying installer files to disk...
Copy complete.
Making disk bootable...
Copying boot files...
Copy complete.
Done.
That's it. The stick is ready.
Step 3: Go update
This is the part, that you'll be repeating on each newly upgraded/installed machine.
Follow the installation procedure and boot to the newly installed macOS. If this doesn't make any sense to you, see my previous article about that.
Step 4: Finishing touches
After boot, you'll end up in a classic login-screen. Login and upgrade will continue there.
The only new items are:
My choices for those new questions are:
- no, absolutely not I won't be storing my data into iCloud, I have the freebie 5 GiB of space there and with my files I'd run out pretty soon
- no, absolutely not I won't be enabling Siri (aka. spy-machine)
Step 5: Done!
That's it, enjoy your upgraded operating system.
Couple of glitches here and there, but the most important one was that my SSH didn't do agent forwarding anymore. I'm not alone with that, other people reported same issue:
ssh -A stopped working in macOS Sierra and keychain is not unlocked at login
The second thing is, that MD5 signed root certificates aren't accepted anymore as default. Unless you're doing some weird shit like I, you won't notice this change. This is fully documented and know before. In optimal world we wouldn't have any MD5 signed root certificates anymore.
Other than those two, I continued using my macs as usual.
Sydney pics
Friday, September 30. 2016
I business in Sydney, Australia and I'm sharing some pics I managed to snap with an iPhone. There wasn't too much time for doing any extensive touristing around, but I managed some.
There is a pic of The Bridge, view to harbor from top floor of one skyscraper on Victoria Street, Opera House and Manly Beach.
Fixing Google's new IPv6 mail policy with Postfix, part 2
Wednesday, September 14. 2016
Book club: Security Engineering
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.
Amazon EC2 spot prices
Friday, August 26. 2016
I was about to do some testing with a cheap Elastic Compute Cloud Linux-instance, but ... AWS wouldn't allocate me one.
Here is the reason from Amazon EC2 Spot Instances Pricing:
Somebody really lost his marbles and is paying ludicrous price for a box.
Ok, in reality that has to be work of two (or more) automated systems competing with each other in a situation where capacity of i2.4xlarge instances is scarce. Any human would do what I did, just pick the bigger box and be happy about that. That instance type with normal pricing costs like $3.41 / hour, and with spot pricing it goes ~60 cents / hour, but not when automated bidding goes haywire.
