Hacker's ramblings

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.

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!

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!

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.