Hacker's ramblings

I got a disc failure. Luckily the server has a RAID, so no imminent data loss occurred. However, it is a RAID-5 setup, so the system performance was impacted heavily.

Now I transferred the entire system into Microsoft Azure and it seems to be running little bit better. The project was a huge one and I had to tinker with it a lot. I guess I'll have to do a full discosure about that later.

Hopefully this thing stays working this time.

This article is specific to an attempt to upload a .vhd image. I did my tinkering with PowerShell running Add-AzureRmVhd command.

My attempt to upload was something like this (backtick ` is just a multi-line character in PowerShell):

Add-AzureRmVhd -ResourceGroupName blog `
  -Destination https://blobs.blob.core.windows.net/vmimages/server.vhd `
  -LocalFilePath '.\disk.vhd'

... and it failed. Exactly like many other people have experienced.

After a while of googling and reading docs, the entire problem/solution became apparent. I was reading article Introduction to Microsoft Azure Storage, which has following note in it:

Note
Blob storage accounts support only block and append blobs, and not page blobs.

To understand the gravity of that is beyond this blog post, but idea is that all .vhd images need to be on a page blob. So, I just created my Azure Storage Account wrong. This is the correct way of doing it:

Make sure the Storage Account type is "General Purpose". To check what you have, go to properties:

Your "Kind" of storage needs to be "Storage" for General Purpose. If you see "Blob Storage", you'll need to do another approach.

There are plenty of good and valid usage for Storage Account of "Blob Storage", but running your VMs isn't one of them.

Somebody has got new toys. I was just doing a casual Speedtest for my mobile subscription to see if it would have any oompf in it. This is the result:

Holy cow! Nearly 150 Mbit/s download. On an iPhone 7! Whaat?
I was just having a burger in Stockholm, my subscription is Finnish, so all the traffic will exit from a Finnish IP-address. That makes the ping bad, but the download speed is trough the roof.

Here are couple of other measurements from Finland (thanks guys for these!):

Similar style results on both cases.

I don't know what changed, but Finnish telcos have really amped it up. No complaints from me! Nice!

Ok, we've established earlier, that IPv6 isnt' getting traction. ISPs are simply to lazy and they don't care about their customers, only their profits matter. It's really bad for profit to do improvements on their systems and networks. Meanwhile IPv4-addresses ran out on IANA, but ISPs don't care about that either, they stockpiled addresses and have plenty to go with.

To get IPv6 on my systems, I've been using free-of-charge service SixXS for almost 10 years. They provide IPv6-on-IPv4 -tunnels using IP-protocol 41 or 6in4. The tunnels I've been using in Finland have been provided by local ISP, DNA, again free-of-charge. During those years of service, I managed to accumulate almost 7000 ISK, that's 5 ISK per week per tunnel, if the tunnel is running without any problems.

On IPv6 day (6th June) 2017 SixSX will shut down all services. See, sunset announcement for their rationale for doing this. They pretty much say, that they ran tunnels for 17 years and don't want to do that anymore, ISPs should provide native IPv6 to every single customer they have. I'm totally agreeing with them. I'd like to keep my tunnels running, still.

It is what it is, decisions have been made and it's not going to change. So, my sincere thanks go to SixXS and DNA, and especially to all the hard working people on those organizations. Thank you for your service!

It took me less than 4 years to finally revisit this subject. I'd like to thank all the people who commented the original blog post. It looks like for those years SystemD (am I writing it wrong?) was in constant evolution and new features were added.

This is what I'm running in production. Containing System and omitting Unit and Install -parts as they are unchanged:

[Service]
Type=forking
PrivateTmp=yes
User=nobody
Group=nobody

RuntimeDirectory=dhis
RuntimeDirectoryMode=0750

ExecStart=/usr/sbin/dhid -P /run/dhis/dhid.pid
PIDFile=/run/dhis/dhid.pid

This also makes my RPM spec-file simpler, I got to remove stuff there, because temporary directory creation is taken care. Finally, I think that this one is done and ready!

If you want to download my source RPM-package, go here.
If you want to know more about RPM-specs, read Maximum RPM - Taking the RPM Package Manager to the Limit.

In my network setup, it's almost done: we have 1) an Internet-connection, 2) a wireless access-point to pass some mobile device traffic trought it, but something is missing: a router to tie it all together. In my post about my Swedish ISP, it became evident, that running a router they threw at me for free wasn't an option. Second completely viable option would be to run my new Wi-Fi AP with DD-WRT as a router. Totally doable. It has all the suitable ports, DD-WRT is fully equipped to act as an internet router and all that.

Me being a total nerd, of course I wanted to build a real router. The suitable hardware for it would be something tiny having enough ports and packing suitable CPU/RAM/SSD to run a real Linux in it. So, my choice for this is:
Qotom Barebone Mini PC Linux Ubuntu Wintel Nano ITX Celeron j1800/1900 Mini Computer Desktop PC Fanless x86 pc Industrial PC Computer. The marketing people at Qotom chose an appropriate name for their product, huh! If I'd choose the name, I'd go anthing with less than 19 words, removed "Ubuntu", "Wintel", double "mini", double "PC" and then start cutting the words into something like: Barebone Fanless Mini ITX PC j1800/1900, or so. But that's only me.

So, at Aliexpress.com it looks like this:

As said, the form-factor is mini-ITX making it a tiny box on the desk. In real life, it looks the same than above marketing material (sorry, pics aren't too good, no DSLR available):

I have no idea who would need 3 x D9 RS-232 -ports, but there they are. My own spec was only to have at least two RJ-45 for Ethernet. This puppy has them with 1Gbit/s speed, adding HDMI and USB-3 on top of that, which are really handy.

Inside the box:

As you can see, there isn't much space around the 17x17 cm mini-ITX -board. The biggest one in the pic is the black cooling block on top of Celeron® J1900 CPU. Close up from the internals:

From left to right:

• Broadcom BCM943224HMP Wi-Fi adapter
• 64 GiB Hoodisk mSATA SSD
• Realtek RTL8168evl dual Ethernet connectors

There is some airspace for cooling inside the box:

For PSU there is an external transformer pushing in 12 VDC at 3 amps:

There is a commonly used IEC C13 on the other end of the transformer to make it easier to plug the thing into your country's choice of wallsocket.

I've been running the box for almost a month now, and I'm very pleased with it. The green power-on LED is way too bright. On a dark room, it illuminates everything with green, but other than that I got the perfect box for a router. As these low-budget boxes are easily available, it's mostly about choosing the most suitable one. Apart from having more than one Ethernet RJ-45, one of my selection criteria for this one was, that the manufacturer didn't take any second guesses about the CPU-cooling. It's easily the biggest block I could find among the competition. On top of that, the manufacturer did deliver the unit from UK-storage quite rapidly. What I missed from seller's page was the fact, that deliveries were made from tax-free -zone. I had to pay Swedish VAT for DHL on top of the purchase price.

My employer was kind enough to issue me new toys. Any proper nerd loves new toys, I know I do!

So, I got an upgrade for my old(ish) iPhone 6. To a rather big surprise, they're exactly the same thing. Here is a quiz for you iPhone-fans. Tell me which one is 6 and which one is 7:

And the easy one:

For the first three pics, I honestly don't know which one is which. The fourth one is an easy one, in iPhone 6 there is a white line right below the camera lens, also the lens is bigger on 7. Fifth one is a no-brainer, no 3.5 mm headphone jack exists in the new one.

Other than the missing jack, there isn't much to tell. Upgrade is almost a no-upgrade. Everything is the same, except I had to spend couple hours of restoring the backup. Actually, there was a quirk, my new phone had latest iOS, but the un-boxed one didn't, so I first had to go through the out-of-box-experience and then upgrade it to latest firmware. Then it was possible to do the restore and after restore the thing could start installing my apps.

List of things that didn't transfer:

• Touch ID fingerprints
  • Apple support HT204136 says that it should, but ...
• Apps from my employer's app store
• Keyboard dictionary
• Ringtone selections
  • I have a dozen or so own-made ringtones for incoming callers.
  • The ringtones did transfer ok, but the selection of which one is used didn't survive the transfer.
• Google Authenticator keys
  • Read the article "Is there an easy way to transfer Google Authenticator codes to a new device?" for reasoning.
• ... maybe something else I forgot to mention here

Ultimately I have to say, this wasn't worth it. I got the same phone without headphone jack, and I had to spend couple hours of work to get a 32 GiB thing to the point I started with a 64 GiB one. It's a shame there is no 64 GiB iPhone 7. They didn't let me get the 128 GiB, because it's too expensive. The new A10 CPU should be more energy efficient, but in reality it doesn't show. Only after upgrading to iOS 10.3.2, there was some improvement on battery usage. Before that, I had to charge the phone more often that my old one.

The only positive thing is, that now I have a fresh battery to my iPhone. I guess I should find some positive things with the new and improved "best ever" camera, but I simply cannot.

In my previous post, I was (not so) politely asking DocuSign to admit e-mail addresses leaking.

Finally, they did! They posted Update 5/16/2017 - Update on Malicious Campaign.

Q: What information was impacted?
A: It was a list of email addresses stored in a separate, non-core system used for service-related announcements.

That is something they should have done a week ago, but I guess we have to settle with that.

Btw. I got my hands on the payload VB:Trojan.VBS.Downloader.ACR as named by F-Secure. As many have reported before, it's a MS Word document with a macro in it. The VBA-thingie de-obfuscates a "picture" embedded into the .doc and injects that directly to memory to be executed. I really didn't want to waste the ton of time investigating the actual malware, its bad, I know that without looking. Its just another reminder of how dangerous the VBA-macros are, they can call any system call from Windows kernel and do really complex hacks, like any real executeable would do.

On 9th and 10th of May I got really weird spam from alleging to originate from DocuSign. The attempt to lure me to hit the link was lame and I didn't believe the communication to be valid at any point. There was no DKIM-signature in the e-mail headers. I know for a fact, that real DocuSign e-mail has that in them. So, any quick analysis of the mail originating from USA and Canada was yelling SPAM! instantly.

The subject of the two first ones was "Completed: Wire Transfer Instructions for docusign Document Ready for Signature" and the third one "subpoena from WEX inc". All of them attempted to get be to download a file from an already shut down websites. All three domains used were 12 characters long .ru-domains and looked random strings to me. I don't know if the words had actual meaning, they just looked random to me. The URLs had my e-mail address Base64-encoded to allow the perps to track any incoming clicks for active e-mails.

Of course plenty of others got the same junk as me, there is a support thread at DocuSign's site: Strange email from Docusign - is it legit? In an answer to that one, the official statement says: "However, DocuSign’s core platform has not been hacked, and our customer data remains secure". In that comment thread there are other people, who don't believe that. I'm one of them.

Why would I make such a bold claim? Well... easy. The e-mail address I'm using in DocuSign is unique. I'm not using that specific address ANYWHERE else. So, people of DocuSign, explain me where the address leaked if not from your system! I guess they claim, that it leaked from one of my systems. But then again, the same thing must have happened for number of other people too. Also, I use hundreds of different addresses for this purpose, to reliably determine which system leaked my information. Any even remotely regular user has their joe.user@mail.com-address registered to dozens and dozens of systems, so they have no possible way of knowing who leaked the data, I do.

I'm urging DocuSign to step forward with a truthful statement about the breach. Their current lies I'm not bying.

Update 15th May:

DocuSign got hacked also two years ago. Same thing happened, they deny any data leakage. Without proof, I feel like throwing unfounded wild allegation here: they have been compromised for over two years now.

In the support discussion thread couple of other people complaining about same thing than I do: the e-mail address isn't being used by anything else than DocuSign, still they're receiving junk to that particular address. How come?

Mirado Consulting was kind enough to host a meetup, with appropriate food & drinks. By that I don't mean the pencil company:

... but a software development consulting agency in Stockholm.

They summoned Mr. Curl, aka. Daniel Stenberg:

... there to talk about HTTP/2 and QUIC, major improvements on HTTP-protocol. His work with network protocols at Mozilla, as author of libcurl/curl and as member of IETF's HTTPbis work group gives a pretty good picture what's happening at the HTTP-scene today. His presentation was titled HTTP/2, the good, the bad and what's next. In that he covered shortcomings of HTTP/1.1, benefits and shortcomings of HTTP/2 and a very likely future of moving away from TCP-based transport protocol into UDP-based QUIC.

Two tidbits from his presentation:

• Current browser implementations use HTTP/2 only with HTTPS:
  • "most client implementations (Firefox, Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory", Wikipedia
  • "Most existing servers only speak HTTP/2 over TLS", Daniel's blog
• HTTP/2 performance is poor on flaky network
  • at 2% packet loss HTTP/2 is at least twice as slow then HTTP/1.1, HTTP/2: What no one is telling you (slide 53) by Hooman Beheshti, VP Technology at Fastly
    

So, it looks like HTTP/2 isn't going to save us from performance bottlenecks of HTTP/1.1 after all. Hence, QUIC.

About CA certificate handling on a Linux system

Finally, as I've written number of posts about TLS/SSL/HTTPS and one of them was about curl's really clumsy way of handling own CA-certificates. Also, I've always hated the fact, that if I'm running Firefox and curl on a Linux and want to add my own CA-root cert there, I need to do that three times:

1. OpenSSL for the everything else in system
2. curl for libcurl -depending apps to have it
3. Firefox

IMHO that's two times too many! On a macOS you do that only once to the keychain and even curl will use that (yes, I confirmed from the man himself).

The reason is Mozilla's policy. NSS, or Network Security Services, a library written by Mozilla is boasting their FIPS 140 Validation and NISCC testing success, which a plain PEM-file in OpenSSL won't provide. That's why they insist on using NSS as storage and making us regular users suffer the pain of having multiple sources of truth.

Finally

Thank you Mirado Consulting for hosting a great event and Daniel for a great presentation!

In my previous post, I un-boxed my new Wi-Fi access point. This is the part for running something in it.

For this to happen, the obvious prerequisite is DD-WRT binary image built specifically for TEW-818DRU. DD-WRT supported devices -list doesn't say much. Little bit of poking around results in build 23720 back in the 2014 for this one. It is at: https://www.dd-wrt.com/site/support/other-downloads?path=betas%2F2014%2F03-13-2014-r23720%2Ftrendnet-818DRU%2F. As I wanted something newer, I went for November 2016 build 30880 at: ftp://ftp.dd-wrt.com/betas/2016/11-14-2016-r30880/trendnet-818DRU/.

My typical approach for flashing new firmware is to stay connected with a wire. In practice that means, that I'll hook up an ethernet cable to my laptop and the other end to the access point's LAN-switch. Then I'll configure a static IP-address at the laptop's operating system. This makes sure, that I'm 100% connected whenever the box is running. Doing this over wireless connection and/or using dynamicly assigned IP-address may or may not work. As these boxes are expensive enough, I didn't push my luck. The downside of this approach is, that I'll need to know what the actual management IP-address will be.

Ok, let's start!

On out-of-box-experience the web GUI is at 192.168.10.1:

After login, there is a nice setup-wizard. Which of course, we'll just skip by acknowleding the alert:

Now we're at the normal administrator environment:

For me, the word "advanced" is like honey to a grizzly bear . I'll always home towards it, I know that all the goodies are stored there:

And also this time I was right, firmware upload/upgrade has its own menu item. Its clear, that this device is 100% designed by engineers, they cannot even seem to be able to agree on a single terminology. Menu has "upload", page title has "upgrade". Any self-respecting user experience designer would yell "You're confusing the user with that!", but I guess this stuff is for nerds only, and they don't care.

After selecting the trendnet-818dru-webflash.bin file to be uploaded, there is yet again a nice warning:

It will take couple minutes for the flashing to complete:

There is very little indication, that the process completed. I didn't notice any lights blinking or something like that. It just completed, rebooted and stayed silent.

Now the IP-addess will change. DD-WRT is 192.168.1.1 at out-of-box-experience:

And that's pretty much it for firmware upgrade. At this point I did my wireless access point -setup including:

• Admin username and password
• AP's LAN IP-address, my LAN isnt' at 192.168.1/24
• Enable SSH-service
• Enable GUI-access for HTTPS and SSH
• Wireless network setup for 2.4 GHz and 5 GHz, WPA2 Personal with pre-shared key as security

DD-WRT is for knowledgeable administrators, no setup wizards or mumbo-jumbo. Just the settings.
Btw. configuration docs can be found at: https://www.dd-wrt.com/wiki/index.php/Configuration_HOWTOs

As I mentioned in my post about Swedish ISP, that I like to run Linux on my stuff. My weapon of choice for wireless networking has been DD-WRT for many years (I'm not sure how many exactly, 15+ or so). Any appliance I purchase must be supported by that.

I've been running a lot of Linksys in the past, but this time I chose to go with a Taiwanese TRENDnet TEW-818DRU. The spec is huge and it contains really good 802.11 radios, USB3-port, decent CPU and enough RAM to run it all. And finally: The manufacturer is really keen on supporting Linux.

This is what it looks like. It won't win any design awards, as obviously some software engineer designed the plastic case:

Linux /proc/cpuinfo for Cortex-A17:

model name : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1594.16
Features : half fastmult edsp tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Memory, physical is 128 MiB, but some is needed for hardware:

             total   used    free shared  buffers  cached
Mem:        124536  38296   86240      0   4108     12212
-/+ buffers/cache:  21976  102560

Ports at the back:

• USB3
• USB2
• WPS-button for those who don't care much for security
• 4 x RJ-45 for LAN
• RJ-45 for WAN
• O/I for power
• Barrel connector for 12 VDC, 2 amps power input

Bottom:

It really doesn't get much simpler than that, which is perfect for engineering type persons. Like me!
You'll get a reliable box with ton on features and possibility of tweaking it to do whatever you need.

In next part I'll put a DD-WRT into it.

It took a lot of time and effort to rent an apartment, Sweden (especially Stockholm are) is notoriously difficult with that. And the first thing any new apartment needs is an Internet-connection. Mobile data in Sweden sucks royally, its expensive and horribly capped with transfer limits. So, something with a wire for me thanks. In this apartment, the options for wired net were highly limited. It's either Comhem or nothing. I chose Comhem.

Back in the 90s, Swedish government subsidied building optical fiber connections to literally every house. They ended up paying roughly 50% of the building costs of proper connections to entire country. Not a bad investment, I have to say. Some businessmen threw rest of the required money and as the result of that, Swedes even today enjoy faster Internet connections than nobody else.

The wall box

Here in Stockholm area this is a very common thing to see:

There is something coming into the box from a hole in a wall. I don't know what that could be, possibly fiber, or possibly something with copper in it. If you know, drop a comment! The output is FM-radio, cable-TV and Internet. Radio and TV are regular 75Ω RF-connectors, something you'd generally expect. Data is an F-connector, also very typical for cable-TV Internet connectivity.

The router

Sorry, the pics are really crappy. I don't have my proper camera here in Sweden, so I have to use whatever mobile junk happens to be at hand. The router looks like this:

In the back there are your expected set of connectors:

• RJ-11: no idea what this is for, my guess is for a landline phone connection (who needs that!?)
• 4 x RJ-45: Your standard 1 Gbit/s ethernet switch
• Reset pin: do a factory reset with a small pointy thingie
• F-connector: for incoming cable-TV signal
• O/I switch: For on-off needs
• Barrel jack: for 12 VDC power connector, 2,5 amps
• (bonus): 2,4 GHz / 5 GHz Wi-Fi router

Bottom:

Yes, this is one of those French-made Sagemcom boxes. Spec is at: F@ST 3686 AC. Sagemcom is quite big in manufacturing consumer boxes for TV/IPTV/cable internet.

There is nothing special nor surprising there in the router. It's your basic free giveaway box the ISPs throw at you when you sign a subscription. Most people love the fact that this one packs a modern Wi-Fi access point. Personally, I hate integrated crap and want to tinker with my access point more than these integrated things allow me to do.

The admin

As you could expect, there is a web-based GUI admin interface at 192.168.0.1:

Logging in gives you more details for the router status:

Wi-Fi settings:

My IP-address, Wi-Fi SSIDs and serial numbers have been redacted, so those of you with evil plans, note that you'll be targeting somebody else.

The speed

I'm subscribing to a Bredband100. The promise is 100 Mbit/s download (actually they say 50-100) and 10 Mbit/s up (range 7-10).

Speedtest, ethernet cable, 1 Gbit/s:

Speedtest, iPhone 6, 802.11ac, 5 GHz:

Speedtest, Asus Nexus 7, 802.11n, 2.4 GHz:

Not bad! They keep the promise.

If you stumble on the Wi-Fi specs, check the article about Wireless N & Wireless G @ Flashrouters blog about those.

The nominal speed of 802.11n is much higher than 63 Mbit/s, but 2.4 GHz is always very saturated. I haven't counted how many wireless access points are visible here to my apartment, but its easily 50+. Also the throughput of a 2.4 GHz Wi-Fi will drop, if any of my neighbours are using a microwave. Cisco claims, that microwave oven interference can reach 25 feet / 7.5 meters, see the article about that. Unfortunately all my toys will support 5 GHz, so I'll have to run both for the time being.

The result

Generally people love hating big corporations, especially ISPs and telcos. I know I do. A good example of that is: Comhem stumbled on my router delivery as their logistics partner started bouncing the shipment back and forth in the same terminal. Eventually I got the router, plugged it in and it worked. Their customer support is good, I called them at least 4 times to get a subscription and for the delivery issues.

After running this box for a week, I have to say it does the job. On a negative side, the router in router/NAT-mode, the router drops your TCP-connections super fast. This mostly affect SSH and as a remedy I have this in my .ssh/config:

Host *
  ServerAliveInterval 25

25 seconds is very fast. Never seen anything like that before. My obvious plan is not disable the wireless AP and switch this baby into a bridge mode and build a real Linux-router to do the NAT. But I'll have to post about that someday.

Ultimately I'm quite happy with this ISP and the router they provided. Out-of-the box it works enough for all people, but provides enough flexibility for me to do some advanced network stuff.

There was bit of a pause in my blogging. Lot of stuff happened during that time and as an end result I moved to Stockholm, Sweden. But hey! Now I have a ton of time to do blogging.

It all started at end of year 2016. My employer at the time was about to be acquired by a big corporation and they asked us if we would relocate and continue working from their Sweden office. I chose to accept their offer and here I am now, in Stockholm.

Around the time the information about the acquisition leaked, I (with the team) spent a while at Stockholm office and rest of the time I just wrapped up my life in Finland.

Anyway, I'll be putting some of my time again to this blog and try to process all the comments I received and even reply to some of them. Thanks for your continued interest in this blog!

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.

Update 20th Apr 2018: There is a follow-up post about installing this into iOS-device.

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

CVE-ID: CVE-2011-3427

Description:
Certificates signed using the MD5 hash algorithm were accepted by iOS. This algorithm has known cryptographic weaknesses. Further research or a misconfigured certificate authority could have allowed the creation of X.509 certificates with attacker controlled values that would have been trusted by the system. This would have exposed X.509 based protocols to spoofing, man in the middle attacks, and information disclosure. This update disables support for an X.509 certificate with an MD5 hash for any use other than as a trusted root certificate.

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:

• SSLv3 cryptographic protocol and the RC4 symmetric cipher suite are no longer supported, starting at the end of 2016. It's recommended that you stop using the SHA-1 and 3DES cryptographic algorithms as soon as possible.

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!

Installation instructions

Should I install the intermediate certificate too?

No.

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.

macOS

For this to work, you'll need

• root access to your Mac
• old MD5 signed root cert
• new SHA-2 signed root cert

First disable trust to the old cert:

security remove-trusted-cert -d CAcert-root.crt 

Remove the old cert by it's signature:

security delete-certificate \
 -Z 135CEC36F49CB8E93B1AB270CD80884676CE8F33 \
 /Library/Keychains/System.keychain

Add and trust the new cert:

security add-trusted-cert -d -r trustRoot \
 -k /Library/Keychains/System.keychain \
 root_256.crt

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.

Windows

For this to work, you'll need

• administrator access to your Windows
• new SHA-2 signed root cert

Remove MD5-signed:

certutil -delstore Root 135CEC36F49CB8E93B1AB270CD80884676CE8F33

Add and trust the new cert:

certutil -addstore Root root_256.crt

Linux

Ah, there are too many distros out there.

Any typical approach would be to place the file into /etc/pki/tls/certs/ and symlink the certificate's OpenSSL hash 99d0fa06.0 into it.

iOS

... This one I'll get back in a later post.