Let's Encrypt ISRG's Root - Fedora curl fix, part 2 - Shared System Certificates
Thursday, August 8. 2019
Let's Encrypt ISRG's Root - Fedora curl fix
Wednesday, August 7. 2019
Update 8th Aug 2019:
The information in this blog post is not the entire truth and less accurate, than I'd hope for. Updated information regarding certificate system in a Fedora linux can be found from this blog post.
Now that Let's Encrypt is issuing their certificates from ISRG Root X1 / Let's Encrypt Authority X3 certificate authority, my Fedora is failing to access sites with curl. I have addressed both of these earlier in articles Let's Encrypt Transitioning to ISRG's Root and Fixing curl with Go Daddy Secure Certificate Authority G2 CA root. However, the previous fixing instructions in modern curl won't work. This is because Fedora guys won't build curl with NSS anymore, but have fallen back to standard OpenSSL used by almost everything else in Linux. Since I'm writing about it, they're doing a bad job about it.
If you'll never use curl or anything built with libcurl, you'll never notice anything. Also, if you're running curl/libcurl but are never accessing any sites with Let's Encrypt certificates, again, you won't notice it. Most of us will notice. Curl will keep spewing errors like "curl: (60) SSL certificate problem: unable to get local issuer certificate" making everybody mad.
Unlike earlier, curl run with --verbose will announce following certificate locations:
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
It so happens, the new intermediate certificate used by Let's Encrypt isn't in the precious ca-bundle.crt file, your connection attempts will fail on a trust issue. You can run the classic OpenSSL certificate fix -operation:
# cd /etc/pki/tls/certs
# wget https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt
# mv letsencryptauthorityx3.pem.txt letsencryptauthorityx3.pem
# openssl rehash
... which will fix a lot in your Fedora, but it won't fix curl. Remember: it will only look inside the /etc/pki/tls/certs/ca-bundle.crt, and you did not add it there.
To get the issue solved for realz, you need to delete the symlink pointing to the certificate bundle file, cook up a new & better one. Like this:
# cd /etc/pki/tls/certs
# rm -f ca-bundle.crt
# cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /tmp/letsencryptauthorityx3.pem > ca-bundle.crt
Now your curl will be tamed. But it won't stick. The first time you'll get an update to RPM-package ca-certificates, your changes are gone and you'll need to re-do them. Gee! Thanks for that.
Bug report is at Curl not using CA-path - custom certificates not used. Go add your comments there to let Fedora guys know how much you appreciate their work! 
Update 8th Aug 2019:
The information in this blog post is not the entire truth and less accurate, than I'd hope for. Updated information regarding certificate system in a Fedora linux can be found from this blog post.
Now that Let's Encrypt is issuing their certificates from ISRG Root X1 / Let's Encrypt Authority X3 certificate authority, my Fedora is failing to access sites with curl. I have addressed both of these earlier in articles Let's Encrypt Transitioning to ISRG's Root and Fixing curl with Go Daddy Secure Certificate Authority G2 CA root. However, the previous fixing instructions in modern curl won't work. This is because Fedora guys won't build curl with NSS anymore, but have fallen back to standard OpenSSL used by almost everything else in Linux. Since I'm writing about it, they're doing a bad job about it.
If you'll never use curl or anything built with libcurl, you'll never notice anything. Also, if you're running curl/libcurl but are never accessing any sites with Let's Encrypt certificates, again, you won't notice it. Most of us will notice. Curl will keep spewing errors like "curl: (60) SSL certificate problem: unable to get local issuer certificate" making everybody mad.
Unlike earlier, curl run with --verbose will announce following certificate locations:
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
It so happens, the new intermediate certificate used by Let's Encrypt isn't in the precious ca-bundle.crt file, your connection attempts will fail on a trust issue. You can run the classic OpenSSL certificate fix -operation:
# cd /etc/pki/tls/certs
# wget https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt
# mv letsencryptauthorityx3.pem.txt letsencryptauthorityx3.pem
# openssl rehash
... which will fix a lot in your Fedora, but it won't fix curl. Remember: it will only look inside the /etc/pki/tls/certs/ca-bundle.crt, and you did not add it there.
To get the issue solved for realz, you need to delete the symlink pointing to the certificate bundle file, cook up a new & better one. Like this:
# cd /etc/pki/tls/certs
# rm -f ca-bundle.crt
# cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /tmp/letsencryptauthorityx3.pem > ca-bundle.crt
Now your curl will be tamed. But it won't stick. The first time you'll get an update to RPM-package ca-certificates, your changes are gone and you'll need to re-do them. Gee! Thanks for that.
Bug report is at Curl not using CA-path - custom certificates not used. Go add your comments there to let Fedora guys know how much you appreciate their work!
EBN European Business Number scam - Part 4 - Epic win!!
Tuesday, June 25. 2019
Couple weeks ago, a good friend of this blog, Mr. Gorila approached with his comment (available at https://blog.hqcodeshop.fi/archives/372-comments.html#c2786). He suggested, that our beloved friends at DAD Gmbh were in some sort of financial trouble. I did some digging of my own, but given the huge handicap of me not knowing any German language nor corporate laws or practices of Germany, I found nothing. Today, Mr. Gorila approached me again with proof.
EBN scammers are Bankrupt!
Its obvious, that the people behind the scam went nowhere. They're still there and are cooking up something while trying to maintain the scam from Cyprus. There are comments from people, who received letters from debt collectors operating from Cyprus. The "debt" in question is from EBN scam and is somehow transferred from DAD Gmbh to CLB Solutions Management.
Regardless of these events, my advice is unchanged: Keep your cool and
DO NOT PAY!
There seems to be increasing amounts of proof of malpractice by DAD Gmbh. Their "debts" are completely ficticious and there is no way they can win anybody in a court of law in Germany. They need to sue your ass in Germany court, and that's there they will lose. They already did that and will keep losing. Actually, "they" don't even manage the company anymore. The company is to be dissolved by court order and liquidation is handled by somebody else than the scammers.
Proof
For those wanting to see the proof, go to https://www.bundesanzeiger.de/ and make a search for "DAD Deutscher Adressdienst". You will receive search result page:
The first result will be the official notification of company liquidation. If you click the link, the text simply says the company will be dissolved and all creditors should contact the company.
More interesting is their balance sheet from year 2017 (printed into PDF by me DAD-scam-Bundesanzeiger-DAD-balance-sheet-2017.pdf). That piece of criminal history needs to stay available as long as there is Internet and human life on Earth.
My most important findings are:
- Scammers have almost 1 million € in accounts receivable. That's ficticious "debt" from marks they scammed.
- Its obvious, that majority of that "income" will never land at their bank accounts. DO NOT PAY!
- Company has nearly 250.000 € cash available
- Two options here: Their liquidation hit them as a surprise or they are really bad at crime.
- It makes no sense to leave any easy-to-move assets to the company.
- Besides the 25.000 € initial capital, that's the profit from their crime. I imagined more.
- Their accumulated operating loss is nearly 100.000 €
- I don't think they ever targeted for profit.
- In a company, it is very easy to avoid taxes by never making any profit out of the operation.
- Stated in balance sheet details: There are almost 400.000€ liabilities remaining
- Given the coarse nature of a balance sheet, I cannot deduce much from that besides they owe more money than they have.
- That kinda explains the liquidation.
Future
They're already running a new scam. It's called European Register of Commerence or ERC. The webpage looks like this:
Its simply a spin-off from EBN-scam with a GDPR-twist.
Participate!
Anybody of you can participate in fighting these scammers. I'm maintaining the Finnish Wikipedia page for EBN scam to have a reputable source of information available with a really good Google page rank. Page is at: https://fi.wikipedia.org/wiki/European_Business_Number
You can do the same in your language!
Keep people informed about these scams. That will make the work for those scammers harder and harder. Many readers have shared information in comments of my blog, please keep doing that! There are people including me, who will investigate your clues and raise awareness of these scams and what happens in the scam'osphere.
Thank you!
Couple weeks ago, a good friend of this blog, Mr. Gorila approached with his comment (available at https://blog.hqcodeshop.fi/archives/372-comments.html#c2786). He suggested, that our beloved friends at DAD Gmbh were in some sort of financial trouble. I did some digging of my own, but given the huge handicap of me not knowing any German language nor corporate laws or practices of Germany, I found nothing. Today, Mr. Gorila approached me again with proof.
EBN scammers are Bankrupt!
Its obvious, that the people behind the scam went nowhere. They're still there and are cooking up something while trying to maintain the scam from Cyprus. There are comments from people, who received letters from debt collectors operating from Cyprus. The "debt" in question is from EBN scam and is somehow transferred from DAD Gmbh to CLB Solutions Management.
Regardless of these events, my advice is unchanged: Keep your cool and
DO NOT PAY!
There seems to be increasing amounts of proof of malpractice by DAD Gmbh. Their "debts" are completely ficticious and there is no way they can win anybody in a court of law in Germany. They need to sue your ass in Germany court, and that's there they will lose. They already did that and will keep losing. Actually, "they" don't even manage the company anymore. The company is to be dissolved by court order and liquidation is handled by somebody else than the scammers.
Proof
For those wanting to see the proof, go to https://www.bundesanzeiger.de/ and make a search for "DAD Deutscher Adressdienst". You will receive search result page:
The first result will be the official notification of company liquidation. If you click the link, the text simply says the company will be dissolved and all creditors should contact the company.
More interesting is their balance sheet from year 2017 (printed into PDF by me DAD-scam-Bundesanzeiger-DAD-balance-sheet-2017.pdf). That piece of criminal history needs to stay available as long as there is Internet and human life on Earth.
My most important findings are:
- Scammers have almost 1 million € in accounts receivable. That's ficticious "debt" from marks they scammed.
- Its obvious, that majority of that "income" will never land at their bank accounts. DO NOT PAY!
- Company has nearly 250.000 € cash available
- Two options here: Their liquidation hit them as a surprise or they are really bad at crime.
- It makes no sense to leave any easy-to-move assets to the company.
- Besides the 25.000 € initial capital, that's the profit from their crime. I imagined more.
- Their accumulated operating loss is nearly 100.000 €
- I don't think they ever targeted for profit.
- In a company, it is very easy to avoid taxes by never making any profit out of the operation.
- Stated in balance sheet details: There are almost 400.000€ liabilities remaining
- Given the coarse nature of a balance sheet, I cannot deduce much from that besides they owe more money than they have.
- That kinda explains the liquidation.
Future
They're already running a new scam. It's called European Register of Commerence or ERC. The webpage looks like this:
Its simply a spin-off from EBN-scam with a GDPR-twist.
Participate!
Anybody of you can participate in fighting these scammers. I'm maintaining the Finnish Wikipedia page for EBN scam to have a reputable source of information available with a really good Google page rank. Page is at: https://fi.wikipedia.org/wiki/European_Business_Number
You can do the same in your language!
Keep people informed about these scams. That will make the work for those scammers harder and harder. Many readers have shared information in comments of my blog, please keep doing that! There are people including me, who will investigate your clues and raise awareness of these scams and what happens in the scam'osphere.
Thank you!
Adding a source of randomness to a Linux
Monday, June 3. 2019
Randomness in computers
You don't need to know much about computers to understand, that computers cannot do random things. Yes, all programming languages and libraries do offer you a rand()-function to emulate randomness. However, the resulting output will follow the carefully crafted programming implementing this "randomness". The most trivial pseudo-random functions will merely provide a sequence of numbers appearing random, but this sequence can be reset to start from beginning making the "randomness" predicatable. That's not really very random, huh!
Improved randomness in computers
To be fair, there does exist improved pseudo-random algorithms which take their initial seed-values from something volatile (time is one such volatile parameter) making the quality of randomness better. Still, even high-quality pseudo-random algorithm is just complex sequence of operations, which will produce duplicate results on same input values. Sometimes its just very tricky to craft a situation where all of the input values would match.
If somebody is capable of doing that, your randomness changes into predictability. Read the story of Dual_EC_DRBG on Wikipedia https://en.wikipedia.org/wiki/Dual_EC_DRBG. When you're generating your precious private keys, you don't want anybody (including NSA) to be able to guess what you have there.
Random source in Linux
Since a proper random source is something every single user, developer and sysadmin would love to have, the problem has been approached on your Linux by authors of the operating system. An excellent description can be found from Wikipedia article https://en.wikipedia.org/wiki//dev/random#Linux. Briefly put, your Linux will collect environmental entropy from number of sources (including human interaction with keyboard and mouse) to a pool, which can then be used to produce naturally random numbers. It actually works very well, the quality of randomness is top-notch.
Obvious problem with this approach is, that you cannot pull too many random numbers out of this source without exhausting it. The fix is to keep typing something while moving your mouse (not a joke!) to generate entropy for the random source. This will eventually help fill the entropy pool and /dev/random will spit couple bytes more.
Those users who have exhausted their /dev/random on an idling rack server without a console keyboard, mouse and video know that it takes painfully long for the entropy pool to fill. A busy server doing something will be able to fill the pool much faster.
A real random source
If you need a real proper random source, which works without human intervention and can provide really good randomness as a stream, there are possibilities on hardware. I know of two good ones, Simtec Electronics Entropy Key and ubld.it TrueRNG Hardware Random Number Generator.
Note: if you consider getting one, get the TrueRNG version 3 (http://ubld.it/truerng_v3). Its just that I have the 1st gen version at hand and haven't found the reason to upgrade.
My TrueRNG looks like this:
It is essentially an USB-stick.
Linux lsusb info essentially identifies it as a Microchip (vendor ID 0x04d8) manufactured USB-device (with ID 0xf5fe) providing RS-232 communications:
Bus 002 Device 009: ID 04d8:f5fe Microchip Technology, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04d8 Microchip Technology, Inc.
idProduct 0xf5fe
bcdDevice 1.00
iManufacturer 1 ubld.it
iProduct 2 TrueRNG
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
And by looking at /dev/, there is a /dev/ttyACM0. That's how udevd will populate a CDC-device when it sees one.
How is this a "true" random source?
Oh, that's easy. The device will produce a random 0 or 1 bit constantly when its on. Or to be precise, there is an internal algorithm producing those based on a constant flow of electrons on a transistor PN-surface. The exact phenomenon is called avalance effect or avalance breakdown. For those who can do electronics, there is a good explanation about this in Difference Between Avalanche Breakdown and Zener Breakdown (I borrowed the visualisation pic from above link).
To (over)simplify that, in a carefully constructed electronic circuit, inside a transistor an electron may or may not be emitted on the other side of a semiconducting surface. The occurrence is as random as it can be in nature. Other circuitry will detect this random flow of electrons (or lack of flow) to produce ones and zeros.
What makes this a really good for randomness, as it is well established that this avalance of electrons will happen. Also, it will happen often enough to produce a stream of events. It's just that we don't know exactly WHEN the avalance of electrons will happen. If you time-slice this to slots, a slot can be empty (no avalance) or full (electrons avalanching).
Linux tweaking:
udev
Anybody having multiple devices in their Linuxes knows, that you really cannot control which device name some specific device will get on reboot. To overcome that, udevd can be instructed to do things when it sees a device. My rules for TrueRNG include setting it to highest possible speed and creating a symlink-device so, that I can point to a known source of random. Also, I'm loosening access to that source of randomness to any users belonging to dialout-group. If I wouldn't do that, only root would have access to this fine random-source.
My /etc/udev/rules.d/99-TrueRNG.rules contains:
SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", SYMLINK+="TrueRNG", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1", GROUP="dialout", MODE="0664"
If you want to take your random-device for a spin, you can do something like:
dd if=/dev/TrueRNG of=random.bytes bs=64 count=1024
That would create a file of 64 KiB containing very very random bytes. In theory you can just cp data out of the character device, but since it has an infite flow, you'll need to cut it at one point.
rngd
Remember the part I said earlier about Linux using your keypresses and mouse movements as entropy source for randomness. Even with the USB-stick popped into a PC, that still remains the case. What needs to be done next is to offer a helping hand to the Linux kernel and make sure the entropy pool is always full.
My Fedora has package called rng-tools. It is packaged from Mr. Horman's https://github.com/nhorman/rng-tools. What's in there are the tools for pumping those precious truly random bits out of the USB-source to Linux kernel's entropy pool. As default, rngd will use /dev/hwrng as the source for randomness. Some Linuxes don't have that device at all, some Linuxes point that into CPU's random source. What's guaranteed, it will not point to your USB-stick! We need to change that.
Btw. you might be horrified by the fact, that something is fidding with your randomness. The exact bits transferred from USB to entropy pool won't be the actual bits getting out of /dev/random. Your keypresses and many other events are still a factor. Its still a good idea to not run randomness-monitoring malware or spyware in your Linux.
Systemd works so, that I did create a copy of /usr/lib/systemd/system/rngd.service into /etc/systemd/system/rngd.service. The contents of the copy in /etc/systemd/system/ can be freely modified and it has priority over the /usr/lib/systemd/system/ one. The only change I made was to have the ExecStart-line say as:
ExecStart=/sbin/rngd -f --rng-device=/dev/TrueRNG --fill-watermark=4000
When rngd-service would be started, it will use the USB-stick as source and make sure, there are at least 4000 bits of entropy in the pool.
Making sure rngd setup works
At any given point, you can query how many bits are available in the Linux entropy-pool:
cat /proc/sys/kernel/random/entropy_avail
Since my setup is working correctly, it will display a number greater than 4000 and smaller than 4096. The upper limit comes from /proc/sys/kernel/random/poolsize, which is a hard-coded number from Linux kernel source.
Hint: If you do the stupid thing like I did and set the /proc/sys/kernel/random/write_wakeup_threshold (using --fill-watermark) into 4096 (or above), your rngd will keep hogging CPU like there is no tomorrow. It is impossible for the pool to contain maximum number of bits at any given time. Give your system a break and set the threshold bit lower than max.
Finally
It's always nice to know for a fact, that random numbers are random. This fact can be verified and has been verified by number of other people.
Enjoy!
Randomness in computers
You don't need to know much about computers to understand, that computers cannot do random things. Yes, all programming languages and libraries do offer you a rand()-function to emulate randomness. However, the resulting output will follow the carefully crafted programming implementing this "randomness". The most trivial pseudo-random functions will merely provide a sequence of numbers appearing random, but this sequence can be reset to start from beginning making the "randomness" predicatable. That's not really very random, huh!
Improved randomness in computers
To be fair, there does exist improved pseudo-random algorithms which take their initial seed-values from something volatile (time is one such volatile parameter) making the quality of randomness better. Still, even high-quality pseudo-random algorithm is just complex sequence of operations, which will produce duplicate results on same input values. Sometimes its just very tricky to craft a situation where all of the input values would match.
If somebody is capable of doing that, your randomness changes into predictability. Read the story of Dual_EC_DRBG on Wikipedia https://en.wikipedia.org/wiki/Dual_EC_DRBG. When you're generating your precious private keys, you don't want anybody (including NSA) to be able to guess what you have there.
Random source in Linux
Since a proper random source is something every single user, developer and sysadmin would love to have, the problem has been approached on your Linux by authors of the operating system. An excellent description can be found from Wikipedia article https://en.wikipedia.org/wiki//dev/random#Linux. Briefly put, your Linux will collect environmental entropy from number of sources (including human interaction with keyboard and mouse) to a pool, which can then be used to produce naturally random numbers. It actually works very well, the quality of randomness is top-notch.
Obvious problem with this approach is, that you cannot pull too many random numbers out of this source without exhausting it. The fix is to keep typing something while moving your mouse (not a joke!) to generate entropy for the random source. This will eventually help fill the entropy pool and /dev/random will spit couple bytes more.
Those users who have exhausted their /dev/random on an idling rack server without a console keyboard, mouse and video know that it takes painfully long for the entropy pool to fill. A busy server doing something will be able to fill the pool much faster.
A real random source
If you need a real proper random source, which works without human intervention and can provide really good randomness as a stream, there are possibilities on hardware. I know of two good ones, Simtec Electronics Entropy Key and ubld.it TrueRNG Hardware Random Number Generator.
Note: if you consider getting one, get the TrueRNG version 3 (http://ubld.it/truerng_v3). Its just that I have the 1st gen version at hand and haven't found the reason to upgrade.
My TrueRNG looks like this:
It is essentially an USB-stick.
Linux lsusb info essentially identifies it as a Microchip (vendor ID 0x04d8) manufactured USB-device (with ID 0xf5fe) providing RS-232 communications:
Bus 002 Device 009: ID 04d8:f5fe Microchip Technology, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04d8 Microchip Technology, Inc.
idProduct 0xf5fe
bcdDevice 1.00
iManufacturer 1 ubld.it
iProduct 2 TrueRNG
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
And by looking at /dev/, there is a /dev/ttyACM0. That's how udevd will populate a CDC-device when it sees one.
How is this a "true" random source?
Oh, that's easy. The device will produce a random 0 or 1 bit constantly when its on. Or to be precise, there is an internal algorithm producing those based on a constant flow of electrons on a transistor PN-surface. The exact phenomenon is called avalance effect or avalance breakdown. For those who can do electronics, there is a good explanation about this in Difference Between Avalanche Breakdown and Zener Breakdown (I borrowed the visualisation pic from above link).
To (over)simplify that, in a carefully constructed electronic circuit, inside a transistor an electron may or may not be emitted on the other side of a semiconducting surface. The occurrence is as random as it can be in nature. Other circuitry will detect this random flow of electrons (or lack of flow) to produce ones and zeros.
What makes this a really good for randomness, as it is well established that this avalance of electrons will happen. Also, it will happen often enough to produce a stream of events. It's just that we don't know exactly WHEN the avalance of electrons will happen. If you time-slice this to slots, a slot can be empty (no avalance) or full (electrons avalanching).
Linux tweaking:
udev
Anybody having multiple devices in their Linuxes knows, that you really cannot control which device name some specific device will get on reboot. To overcome that, udevd can be instructed to do things when it sees a device. My rules for TrueRNG include setting it to highest possible speed and creating a symlink-device so, that I can point to a known source of random. Also, I'm loosening access to that source of randomness to any users belonging to dialout-group. If I wouldn't do that, only root would have access to this fine random-source.
My /etc/udev/rules.d/99-TrueRNG.rules contains:
SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", SYMLINK+="TrueRNG", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1", GROUP="dialout", MODE="0664"
If you want to take your random-device for a spin, you can do something like:
dd if=/dev/TrueRNG of=random.bytes bs=64 count=1024
That would create a file of 64 KiB containing very very random bytes. In theory you can just cp data out of the character device, but since it has an infite flow, you'll need to cut it at one point.
rngd
Remember the part I said earlier about Linux using your keypresses and mouse movements as entropy source for randomness. Even with the USB-stick popped into a PC, that still remains the case. What needs to be done next is to offer a helping hand to the Linux kernel and make sure the entropy pool is always full.
My Fedora has package called rng-tools. It is packaged from Mr. Horman's https://github.com/nhorman/rng-tools. What's in there are the tools for pumping those precious truly random bits out of the USB-source to Linux kernel's entropy pool. As default, rngd will use /dev/hwrng as the source for randomness. Some Linuxes don't have that device at all, some Linuxes point that into CPU's random source. What's guaranteed, it will not point to your USB-stick! We need to change that.
Btw. you might be horrified by the fact, that something is fidding with your randomness. The exact bits transferred from USB to entropy pool won't be the actual bits getting out of /dev/random. Your keypresses and many other events are still a factor. Its still a good idea to not run randomness-monitoring malware or spyware in your Linux.
Systemd works so, that I did create a copy of /usr/lib/systemd/system/rngd.service into /etc/systemd/system/rngd.service. The contents of the copy in /etc/systemd/system/ can be freely modified and it has priority over the /usr/lib/systemd/system/ one. The only change I made was to have the ExecStart-line say as:
ExecStart=/sbin/rngd -f --rng-device=/dev/TrueRNG --fill-watermark=4000
When rngd-service would be started, it will use the USB-stick as source and make sure, there are at least 4000 bits of entropy in the pool.
Making sure rngd setup works
At any given point, you can query how many bits are available in the Linux entropy-pool:
cat /proc/sys/kernel/random/entropy_avail
Since my setup is working correctly, it will display a number greater than 4000 and smaller than 4096. The upper limit comes from /proc/sys/kernel/random/poolsize, which is a hard-coded number from Linux kernel source.
Hint: If you do the stupid thing like I did and set the /proc/sys/kernel/random/write_wakeup_threshold (using --fill-watermark) into 4096 (or above), your rngd will keep hogging CPU like there is no tomorrow. It is impossible for the pool to contain maximum number of bits at any given time. Give your system a break and set the threshold bit lower than max.
Finally
It's always nice to know for a fact, that random numbers are random. This fact can be verified and has been verified by number of other people.
Enjoy!
Let's Encrypt Transitioning to ISRG's Root
Sunday, May 5. 2019
Over an year ago, I posted a piece regarding Let's Encrypt and specifically me starting to use their TLS certificates. This certificate operation they're running is bit weird, but since their price for a X.509 cert is right (they're free-of-charge), they're very popular (yes, very very popular) I chose to jump into their wagon.
In my previous post I had this flowchart depicting their (weird) chain of trust:
I'm not going to repeat the stuff here, just go read the post. It is simply weird to see a CHAIN of trust not being a chain. Technically a X.509 certificate can be issued by only one issuer, not by two.
Last month they announced, they're going this way:
What is this change and how will it affect me?
Read the announcement at https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html. There is a very good chance, it will not affect you. Its more like a change in internal operation of the system. The change WILL take place on 8th of July this year and any certificates issued by users like me and you will originate from a new intermediate CA using a certificate issued by ISRG's own CA. So, the change won't take place instantly. What will happen is, for the period of 90 days (the standard lifetime of a Let's Encrypt certificate) after 8th July, sites will eventually transition to these new certificates.
The part where it might have an impact to you is with legacy devices, browsers, operating systems, etc. Especially, if you're one of the unhappy legacy Android mobile users, it WILL affect you. Lot of concerned people are discussing this change at https://community.letsencrypt.org/t/please-reconsider-defaulting-to-the-isrg-root-its-unsupported-by-more-than-50-of-android-phones/91485. If you're smart enough to avoid those crappy and insecure 'droids not having any security patches by a mobile vendor who doesn't care about your security, then this will not affect you.
Testing - A peek into the future
The way Let's Encrypt does their business is weird. I have stated that opinion a number of times. However, as they are weird, they are not incompetent. A test site has existed for a long time at https://valid-isrgrootx1.letsencrypt.org/, where you can see what will happen after July 8th 2019.
On any browser, platform or device I did my testing: everything worked without problems. List of tested browsers, platforms and devices will include:
- Anything regular you might have on your devices
- Safari on multiple Apple iOS 12 mobile devices
- Chrome on Huawei Honor P9 running Android 8
- Microsoft Edge Insider (the Chrome-based browser)
- Safari Technology Preview (macOS Safari early release branch)
- Firefox 66 on Linux
- Curl 7.61 on Linux
An attempt to explain the flowchart
Yes, any topic addressing certificates, cryptography and their applications is always on the complex side of things. Most likely this explanation of mine won't clarify anything, but give me some credit for trying. 
In an attempt to de-chiper the flowchart and put some sense to a chain-not-being-a-chain-but-a-net, let's take a look into the certificate chain details. Some things there are exactly the same, some things there are completely different.
Chain for an old certificate, issued before 8th July
Command: openssl s_client -showcerts -connect letsencrypt.org:443
Will output:
CONNECTED(00000003)
---
Certificate chain
0 s:CN = www.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIHMjCCBhqgAwIBAgISA2YsTPFE5kGjwkzWw/oSohXVMA0GCSqGSIb3DQEBCwUA
...
gRNK7nhFsbBSxaKqLaSCVPak8siUFg==
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
...
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = www.letsencrypt.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
...
Chain for a new certificate, issued after 8th July
Command: openssl s_client -showcerts -connect valid-isrgrootx1.letsencrypt.org:443
Will output:
CONNECTED(00000003)
---
Certificate chain
0 s:CN = valid-isrgrootx1.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIFdjCCBF6gAwIBAgISA9d+OzySGokxL64OccKNS948MA0GCSqGSIb3DQEBCwUA
...
yEnNbd5O8Iz2Nw==
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFjTCCA3WgAwIBAgIRANOxciY0IzLc9AUoUSrsnGowDQYJKoZIhvcNAQELBQAw
...
rUCGwbCUDI0mxadJ3Bz4WxR6fyNpBK2yAinWEsikxqEt
-----END CERTIFICATE-----
---
Server certificate
subject=CN = valid-isrgrootx1.letsencrypt.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
...
But look the same!
Not really, looks can be deceiving. It's always in the details. The important difference is in level 1 certificate, having different issuer. Given cryptographny, the actual bytes transmitted on the wire are of course different as any minor change in a cert details will result in a completely different result.
As a not-so-important fact, the level 0 certificates are complately different, because they are for different web site.
Then again the level 1 certs are the same, both do have the same private key. There is no difference in the 2048-bit RSA modulus:
Certificate:
Data:
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:9c:d3:0c:f0:5a:e5:2e:47:b7:72:5d:37:83:b3:
68:63:30:ea:d7:35:26:19:25:e1:bd:be:35:f1:70:
92:2f:b7:b8:4b:41:05:ab:a9:9e:35:08:58:ec:b1:
2a:c4:68:87:0b:a3:e3:75:e4:e6:f3:a7:62:71:ba:
79:81:60:1f:d7:91:9a:9f:f3:d0:78:67:71:c8:69:
0e:95:91:cf:fe:e6:99:e9:60:3c:48:cc:7e:ca:4d:
77:12:24:9d:47:1b:5a:eb:b9:ec:1e:37:00:1c:9c:
ac:7b:a7:05:ea:ce:4a:eb:bd:41:e5:36:98:b9:cb:
fd:6d:3c:96:68:df:23:2a:42:90:0c:86:74:67:c8:
7f:a5:9a:b8:52:61:14:13:3f:65:e9:82:87:cb:db:
fa:0e:56:f6:86:89:f3:85:3f:97:86:af:b0:dc:1a:
ef:6b:0d:95:16:7d:c4:2b:a0:65:b2:99:04:36:75:
80:6b:ac:4a:f3:1b:90:49:78:2f:a2:96:4f:2a:20:
25:29:04:c6:74:c0:d0:31:cd:8f:31:38:95:16:ba:
a8:33:b8:43:f1:b1:1f:c3:30:7f:a2:79:31:13:3d:
2d:36:f8:e3:fc:f2:33:6a:b9:39:31:c5:af:c4:8d:
0d:1d:64:16:33:aa:fa:84:29:b6:d4:0b:c0:d8:7d:
c3:93
New certificate from a GUI
Obviously, the same thing can be observed from your favorite browser. Not everybody loves doing most of the really important things from a command-line-interface.
Old one, having DST-root:
New one, having ISRG-root:
Completely different. Same, but different.
Confusion - Bug in Firefox
Chrome, correctly displaying DST-root for www.letsencypt.org:
Firefox failing to follow the certificate chain correctly for the same site:
This is the stuff where everybody (including me) gets confused. Firefox fails to display the correct issuer information! For some reason, it already displays the new intermediate and root information for https://letsencrypt.org/.
Most likely this happens because both of the intermediate CA certificates are using the same private key. I don't know this for sure, but it is entirely possible, that Mozilla TLS-stack is storing information per private key and something is lost during processing. Another explanation might be, that lot of Mozilla guys do work closely with Let's Encrypt and they have hard-coded the chain into Firefox.
Finally
Confused?
Naah. Just ignore this change. This is Internet! There is constantly something changing.
Over an year ago, I posted a piece regarding Let's Encrypt and specifically me starting to use their TLS certificates. This certificate operation they're running is bit weird, but since their price for a X.509 cert is right (they're free-of-charge), they're very popular (yes, very very popular) I chose to jump into their wagon.
In my previous post I had this flowchart depicting their (weird) chain of trust:
I'm not going to repeat the stuff here, just go read the post. It is simply weird to see a CHAIN of trust not being a chain. Technically a X.509 certificate can be issued by only one issuer, not by two.
Last month they announced, they're going this way:
What is this change and how will it affect me?
Read the announcement at https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html. There is a very good chance, it will not affect you. Its more like a change in internal operation of the system. The change WILL take place on 8th of July this year and any certificates issued by users like me and you will originate from a new intermediate CA using a certificate issued by ISRG's own CA. So, the change won't take place instantly. What will happen is, for the period of 90 days (the standard lifetime of a Let's Encrypt certificate) after 8th July, sites will eventually transition to these new certificates.
The part where it might have an impact to you is with legacy devices, browsers, operating systems, etc. Especially, if you're one of the unhappy legacy Android mobile users, it WILL affect you. Lot of concerned people are discussing this change at https://community.letsencrypt.org/t/please-reconsider-defaulting-to-the-isrg-root-its-unsupported-by-more-than-50-of-android-phones/91485. If you're smart enough to avoid those crappy and insecure 'droids not having any security patches by a mobile vendor who doesn't care about your security, then this will not affect you.
Testing - A peek into the future
The way Let's Encrypt does their business is weird. I have stated that opinion a number of times. However, as they are weird, they are not incompetent. A test site has existed for a long time at https://valid-isrgrootx1.letsencrypt.org/, where you can see what will happen after July 8th 2019.
On any browser, platform or device I did my testing: everything worked without problems. List of tested browsers, platforms and devices will include:
- Anything regular you might have on your devices
- Safari on multiple Apple iOS 12 mobile devices
- Chrome on Huawei Honor P9 running Android 8
- Microsoft Edge Insider (the Chrome-based browser)
- Safari Technology Preview (macOS Safari early release branch)
- Firefox 66 on Linux
- Curl 7.61 on Linux
An attempt to explain the flowchart
Yes, any topic addressing certificates, cryptography and their applications is always on the complex side of things. Most likely this explanation of mine won't clarify anything, but give me some credit for trying.
In an attempt to de-chiper the flowchart and put some sense to a chain-not-being-a-chain-but-a-net, let's take a look into the certificate chain details. Some things there are exactly the same, some things there are completely different.
Chain for an old certificate, issued before 8th July
Command: openssl s_client -showcerts -connect letsencrypt.org:443
Will output:
CONNECTED(00000003)
---
Certificate chain
0 s:CN = www.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIHMjCCBhqgAwIBAgISA2YsTPFE5kGjwkzWw/oSohXVMA0GCSqGSIb3DQEBCwUA
...
gRNK7nhFsbBSxaKqLaSCVPak8siUFg==
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
...
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = www.letsencrypt.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
...
Chain for a new certificate, issued after 8th July
Command: openssl s_client -showcerts -connect valid-isrgrootx1.letsencrypt.org:443
Will output:
CONNECTED(00000003)
---
Certificate chain
0 s:CN = valid-isrgrootx1.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIFdjCCBF6gAwIBAgISA9d+OzySGokxL64OccKNS948MA0GCSqGSIb3DQEBCwUA
...
yEnNbd5O8Iz2Nw==
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFjTCCA3WgAwIBAgIRANOxciY0IzLc9AUoUSrsnGowDQYJKoZIhvcNAQELBQAw
...
rUCGwbCUDI0mxadJ3Bz4WxR6fyNpBK2yAinWEsikxqEt
-----END CERTIFICATE-----
---
Server certificate
subject=CN = valid-isrgrootx1.letsencrypt.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
...
But look the same!
Not really, looks can be deceiving. It's always in the details. The important difference is in level 1 certificate, having different issuer. Given cryptographny, the actual bytes transmitted on the wire are of course different as any minor change in a cert details will result in a completely different result.
As a not-so-important fact, the level 0 certificates are complately different, because they are for different web site.
Then again the level 1 certs are the same, both do have the same private key. There is no difference in the 2048-bit RSA modulus:
Certificate:
Data:
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:9c:d3:0c:f0:5a:e5:2e:47:b7:72:5d:37:83:b3:
68:63:30:ea:d7:35:26:19:25:e1:bd:be:35:f1:70:
92:2f:b7:b8:4b:41:05:ab:a9:9e:35:08:58:ec:b1:
2a:c4:68:87:0b:a3:e3:75:e4:e6:f3:a7:62:71:ba:
79:81:60:1f:d7:91:9a:9f:f3:d0:78:67:71:c8:69:
0e:95:91:cf:fe:e6:99:e9:60:3c:48:cc:7e:ca:4d:
77:12:24:9d:47:1b:5a:eb:b9:ec:1e:37:00:1c:9c:
ac:7b:a7:05:ea:ce:4a:eb:bd:41:e5:36:98:b9:cb:
fd:6d:3c:96:68:df:23:2a:42:90:0c:86:74:67:c8:
7f:a5:9a:b8:52:61:14:13:3f:65:e9:82:87:cb:db:
fa:0e:56:f6:86:89:f3:85:3f:97:86:af:b0:dc:1a:
ef:6b:0d:95:16:7d:c4:2b:a0:65:b2:99:04:36:75:
80:6b:ac:4a:f3:1b:90:49:78:2f:a2:96:4f:2a:20:
25:29:04:c6:74:c0:d0:31:cd:8f:31:38:95:16:ba:
a8:33:b8:43:f1:b1:1f:c3:30:7f:a2:79:31:13:3d:
2d:36:f8:e3:fc:f2:33:6a:b9:39:31:c5:af:c4:8d:
0d:1d:64:16:33:aa:fa:84:29:b6:d4:0b:c0:d8:7d:
c3:93
New certificate from a GUI
Obviously, the same thing can be observed from your favorite browser. Not everybody loves doing most of the really important things from a command-line-interface.
Old one, having DST-root:
New one, having ISRG-root:
Completely different. Same, but different.
Confusion - Bug in Firefox
Chrome, correctly displaying DST-root for www.letsencypt.org:
Firefox failing to follow the certificate chain correctly for the same site:
This is the stuff where everybody (including me) gets confused. Firefox fails to display the correct issuer information! For some reason, it already displays the new intermediate and root information for https://letsencrypt.org/.
Most likely this happens because both of the intermediate CA certificates are using the same private key. I don't know this for sure, but it is entirely possible, that Mozilla TLS-stack is storing information per private key and something is lost during processing. Another explanation might be, that lot of Mozilla guys do work closely with Let's Encrypt and they have hard-coded the chain into Firefox.
Finally
Confused?
Naah. Just ignore this change. This is Internet! There is constantly something changing.
Ransom email scam - How to mass extort bitcoins via spam campaign
Thursday, May 2. 2019
I've been receiving couple of these already:
Hello!
This is important information for you!
Some months ago I hacked your OS and got full access to your account one-of-my-emails@redacted
On day of hack your account one-of-my-emails@redacted has password: m7wgwpr7
So, you can change the password, yes.. Or already changed... But my malware intercepts it every time.
How I made it:
In the software of the router, through which you went online, was a vulnerability. I used it...
If you interested you can read about it: CVE-2019-1663 - a vulnerability in the web-based management interface of the Cisco routers. I just hacked this router and placed my malicious code on it. When you went online, my trojan was installed on the OS of your device.
After that, I made a full backup of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).
A month ago, I wanted to lock your device and ask for a not big amount of btc to unlock. But I looked at the sites that you regularly visit, and I was shocked by what I saw!!! I'm talk you about sites for adults.
I want to say - you are a BIG pervert. Your fantasy is shifted far away from the normal course!
And I got an idea.... I made a screenshot of the adult sites where you have fun (do you understand what it is about, huh?). After that, I made a screenshot of your joys (using the camera of your device) and glued them together. Turned out amazing! You are so spectacular!
I'm know that you would not like to show these screenshots to your friends, relatives or colleagues.
I think $748 is a very, very small amount for my silence. Besides, I have been spying on you for so long, having spent a lot of time!
Pay ONLY in Bitcoins!
Note: That is only the beginning of long rambling to make me convinced this is for real.
The good thing is, that I finally found my lost password. As stated in the scam mail, it is: m7wgwpr7
Wait a minute! Nobody should post their passwords publicly! No worries, I'll post all of mine. You can find them from https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt As a careful Internet user, I only use passwords from that one million -list.
Also, thank you for informing me about a security flaw allowing remote code execution in my Cisco RV110W Wireless-N VPN Firewall, Cisco RV130W Wireless-N Multifunction VPN Router or Cisco RV215W Wireless-N VPN Router. I don't know exactly which one of those I have. I may need to re-read CVE-2019-1663 Detail again for details.
Good thing you mentioned, that you are capable of intercepting my attempts of changing my account password. I'm too scared to use Internet anywhere else than through my Cisco <whatever the model was> router. I'll never use my cell phone, office network or any public Wi-Fi for Internet access.
Nice job on finding the camera in one of my desktop PCs. I personally haven't found any in them yet!
Also I'm happy to know, that now somebody has backups of all my Windowses, Macs and Linuxes I use on regular basis. Including my NAS, that's nearly 20 terabytes of data! Transferring all that out of my Internet connections without me noticing anything is really a feat. Congrats on that one!
PS. Are you for real! 
I've been receiving couple of these already:
Hello!
This is important information for you!
Some months ago I hacked your OS and got full access to your account one-of-my-emails@redacted
On day of hack your account one-of-my-emails@redacted has password: m7wgwpr7
So, you can change the password, yes.. Or already changed... But my malware intercepts it every time.
How I made it:
In the software of the router, through which you went online, was a vulnerability. I used it...
If you interested you can read about it: CVE-2019-1663 - a vulnerability in the web-based management interface of the Cisco routers. I just hacked this router and placed my malicious code on it. When you went online, my trojan was installed on the OS of your device.
After that, I made a full backup of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).
A month ago, I wanted to lock your device and ask for a not big amount of btc to unlock. But I looked at the sites that you regularly visit, and I was shocked by what I saw!!! I'm talk you about sites for adults.
I want to say - you are a BIG pervert. Your fantasy is shifted far away from the normal course!
And I got an idea.... I made a screenshot of the adult sites where you have fun (do you understand what it is about, huh?). After that, I made a screenshot of your joys (using the camera of your device) and glued them together. Turned out amazing! You are so spectacular!
I'm know that you would not like to show these screenshots to your friends, relatives or colleagues.
I think $748 is a very, very small amount for my silence. Besides, I have been spying on you for so long, having spent a lot of time!
Pay ONLY in Bitcoins!
Note: That is only the beginning of long rambling to make me convinced this is for real.
The good thing is, that I finally found my lost password. As stated in the scam mail, it is: m7wgwpr7
Wait a minute! Nobody should post their passwords publicly! No worries, I'll post all of mine. You can find them from https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt As a careful Internet user, I only use passwords from that one million -list.
Also, thank you for informing me about a security flaw allowing remote code execution in my Cisco RV110W Wireless-N VPN Firewall, Cisco RV130W Wireless-N Multifunction VPN Router or Cisco RV215W Wireless-N VPN Router. I don't know exactly which one of those I have. I may need to re-read CVE-2019-1663 Detail again for details.
Good thing you mentioned, that you are capable of intercepting my attempts of changing my account password. I'm too scared to use Internet anywhere else than through my Cisco <whatever the model was> router. I'll never use my cell phone, office network or any public Wi-Fi for Internet access.
Nice job on finding the camera in one of my desktop PCs. I personally haven't found any in them yet!
Also I'm happy to know, that now somebody has backups of all my Windowses, Macs and Linuxes I use on regular basis. Including my NAS, that's nearly 20 terabytes of data! Transferring all that out of my Internet connections without me noticing anything is really a feat. Congrats on that one!
PS. Are you for real!
StackExchange flair received
Monday, March 11. 2019
Whoa! I finally hit the long awaited 200 point mark in Stack Overflow. The good part about that is, Stack Exchange starts publishing a public badge they'll call "flair". They do this to make it possible for me to publicly boast about my prowess. To get some public boasting going on, my flair looks like this:
All of you Peeping Toms out there, I'll save you couple keystrokes of googling: My 
public user profile is at https://stackexchange.com/users/1684769/hqjatu
Whoa! I finally hit the long awaited 200 point mark in Stack Overflow. The good part about that is, Stack Exchange starts publishing a public badge they'll call "flair". They do this to make it possible for me to publicly boast about my prowess. To get some public boasting going on, my flair looks like this:
All of you Peeping Toms out there, I'll save you couple keystrokes of googling: My public user profile is at https://stackexchange.com/users/1684769/hqjatu
Facebook security flaw - New accounts created on my email
Thursday, October 18. 2018
Couple days ago 8pm, I got an email from Facebook. Personally, I think face book is a criminal organization and want absolutely nothing to do with the idiots. Given the nature of the email, I started investigating:
Yeah, right. Like I would create an account there. And if I would, I wouldn't use any of my proper emails. Their information gathering from non-users is criminal and they do know pretty much everything there is to know about me. Still, I wouldn't give them anything too easily.
I did confirm the time. I wasn't even using a computer when above mail was received. So, I'm claiming, it wasn't me!
Things started getting really weird, when these arrived:
Somebody from New Jersey, USA had reset the password for this newly created account. How nice of them!
Also, there was some trouble logging in. Well that can happen, when you're hacking.
Given the option in the mail, I did click the "If you didn't do this, please secure your account". The first thing they want from me is my phone number. Again, they need to steal that information from me, I'm not going to GIVE it to them. Without verified mobile number, face-jerks let me do nothing. I cannot report the security incident. I cannot request closing the account. There is absolutely no options before entering my phone number. Nobody at super-smart face book anticipated things like this to happen. I really love their service design there!
Just to make sure, I did check my email logins at my service provider. No suspicious activity there. I did reply to security@facebookmail.com regarding this security incident, but I really don't have my hopes up. If somewhere there's a nipple visible or just regular business presentation, then the jerks at FB will censor the material in 5 minutes. When something really serious happens, they don't care. Their only motivator is the stock price. Visible nipples can threaten their revenues, security incidents to so much.
My guess is, that after their last incident (see: Relax, just 30 million Facebook accounts were compromised after all), there is lot of people wanting to crack the site. To me it looks like, somebody is progressing with the attempt and using my mail account at it.
Couple days ago 8pm, I got an email from Facebook. Personally, I think face book is a criminal organization and want absolutely nothing to do with the idiots. Given the nature of the email, I started investigating:
Yeah, right. Like I would create an account there. And if I would, I wouldn't use any of my proper emails. Their information gathering from non-users is criminal and they do know pretty much everything there is to know about me. Still, I wouldn't give them anything too easily.
I did confirm the time. I wasn't even using a computer when above mail was received. So, I'm claiming, it wasn't me!
Things started getting really weird, when these arrived:
Somebody from New Jersey, USA had reset the password for this newly created account. How nice of them!
Also, there was some trouble logging in. Well that can happen, when you're hacking.
Given the option in the mail, I did click the "If you didn't do this, please secure your account". The first thing they want from me is my phone number. Again, they need to steal that information from me, I'm not going to GIVE it to them. Without verified mobile number, face-jerks let me do nothing. I cannot report the security incident. I cannot request closing the account. There is absolutely no options before entering my phone number. Nobody at super-smart face book anticipated things like this to happen. I really love their service design there!
Just to make sure, I did check my email logins at my service provider. No suspicious activity there. I did reply to security@facebookmail.com regarding this security incident, but I really don't have my hopes up. If somewhere there's a nipple visible or just regular business presentation, then the jerks at FB will censor the material in 5 minutes. When something really serious happens, they don't care. Their only motivator is the stock price. Visible nipples can threaten their revenues, security incidents to so much.
My guess is, that after their last incident (see: Relax, just 30 million Facebook accounts were compromised after all), there is lot of people wanting to crack the site. To me it looks like, somebody is progressing with the attempt and using my mail account at it.
DocuSign hacked: Fallout of leaked E-mail addresses
Sunday, September 23. 2018
Over an year ago, DocuSign was hacked (again). Initially they denied the entire thing, but eventually they had to come clean about their userbase being leaked. I think their wording was, that only email addresses were stolen, but ... given their lack of transparency I wouldn't take their word on that. Read my post about the 2017 incident.
After the May 2017 leak, I've received at least dozen emails to my DocuSign address. For the jerks pulling the userbase, it surely has been a source of joy, a gift that keeps on giving.
Couple days ago I got one of these:
Looks like a perfectly valid DocuSign you've-got-mail -announcement, except it has a really funny recipient address, DocuSign knows my real name. Also, the link won't land on DocuSign website. The Sign Invoice -link doesn't even have HTTPS-address, which is pretty much mandatory after July 24th 2018, so without a doubt it is a fake. I'm not sure if its sensible to publish the UID of CRIQQABU2AHOQ0TUYBUD or the code E1ABA59517. Doing that might bite me later, but its done already.
At the time of writing, GoDaddy took the entire target site down. Obviously, some innocent website (most likely a WordPress) got re-purposed to act as DocuSign "mirror" harvesting data of click-baitable victims and offering them malware and/or junk. GoDaddy is notorious for taking down domains and websites on a hint of a complaint, so I really cannot comprehend why anybody would want to use their services. Given their enormous size, most of their paying customers won't realize, that anybody can take any GoDaddy-hosted site down in a jiffy. But that's the way the World works, you harvest money from the unware.
DocuSign is learning, slowly, but looks like the direction is correct. Their website (https://www.docusign.com/trust) has words "Transparency is essential" in it. Yup. That's right. Your mess, own it! This time they actually do own it, they published an alert ALERT:09/19/2018 @ 9.03 AM Pacific Time - New Phishing Campaign Observed Today. That's what you do when somebody pwns you and your entire userbase get stolen. Good job!
It remains to be seen, if those buggers dare to deny their next leak. So far I'm not trusting those liars, but I'm liking their new approach.
Over an year ago, DocuSign was hacked (again). Initially they denied the entire thing, but eventually they had to come clean about their userbase being leaked. I think their wording was, that only email addresses were stolen, but ... given their lack of transparency I wouldn't take their word on that. Read my post about the 2017 incident.
After the May 2017 leak, I've received at least dozen emails to my DocuSign address. For the jerks pulling the userbase, it surely has been a source of joy, a gift that keeps on giving.
Couple days ago I got one of these:
Looks like a perfectly valid DocuSign you've-got-mail -announcement, except it has a really funny recipient address, DocuSign knows my real name. Also, the link won't land on DocuSign website. The Sign Invoice -link doesn't even have HTTPS-address, which is pretty much mandatory after July 24th 2018, so without a doubt it is a fake. I'm not sure if its sensible to publish the UID of CRIQQABU2AHOQ0TUYBUD or the code E1ABA59517. Doing that might bite me later, but its done already.
At the time of writing, GoDaddy took the entire target site down. Obviously, some innocent website (most likely a WordPress) got re-purposed to act as DocuSign "mirror" harvesting data of click-baitable victims and offering them malware and/or junk. GoDaddy is notorious for taking down domains and websites on a hint of a complaint, so I really cannot comprehend why anybody would want to use their services. Given their enormous size, most of their paying customers won't realize, that anybody can take any GoDaddy-hosted site down in a jiffy. But that's the way the World works, you harvest money from the unware.
DocuSign is learning, slowly, but looks like the direction is correct. Their website (https://www.docusign.com/trust) has words "Transparency is essential" in it. Yup. That's right. Your mess, own it! This time they actually do own it, they published an alert ALERT:09/19/2018 @ 9.03 AM Pacific Time - New Phishing Campaign Observed Today. That's what you do when somebody pwns you and your entire userbase get stolen. Good job!
It remains to be seen, if those buggers dare to deny their next leak. So far I'm not trusting those liars, but I'm liking their new approach.
Automating IPMI 2.0 management Let's Encrypt certificate update
Thursday, July 12. 2018
RFID Mifare Classic "clone"
Saturday, April 21. 2018
Toying around with RFID, tags has always been something I wanted to do, but never had the time. Contactless payment is gaining traction all around the world. The reason is very simple: it is fast and convenient for both the customer and vendor to just touch'n'go with your credit card or mobile phone on a point-of-sale.
Credit/Debit card payments are based on EMV, or Europay MasterCard and Visa, standard. See generic EMV info at https://en.wikipedia.org/wiki/EMV. Back in 2011 Visa started driving the contactless standard worldwide, and given the situation today, their efforts paid off. However, my understanding is, that at the time of writing this, regardless number of people attempting it, there are no known vulnerabilities in the contactless EMV. Finding one, would be sweet, but finding one would also be extremely hard and time consuming. So, I decided to go for something easier. MIFARE Classic.
What's this RFID, isn't it NFC?
Short answer: yes and no.
Long answer:
This infographic is courtesy of atlasRFIDstore
http://blog.atlasrfidstore.com/rfid-vs-nfc
MIFARE Classic info
Since this topic isn't especially new, I'm just posting some useful sites I found to be very useful when doing RFID-hacks:
- Finding the encryption keys:
- Cloning the tag:
- Information about Mifare Classic encryption key hacking:
- ISO/IEC 14443 Type A generations:
Going to eBay for the hardware
I had a real-world RFID -tag, and wanted to take a peek into it. For that to happen, I needed some hardware.
The choice for reader/writer is obvious, an ACR122. Info is at: https://www.acs.com.hk/en/products/3/acr122u-usb-nfc-reader/. The thing costs almost nothing and is extremely well supported by all kinds of hacking software.
Going to GitHub for the software
All the software needed in this project can be found from GitHub:
- libusb, https://github.com/libusb/libusb
- Some software want libusb 0.1 some 1.0. I had only 0.1 installed so I had to compile the latest also.
- libnfc, https://github.com/nfc-tools/libnfc
- Latest installed
- MiFare Classic Universal toolKit, mfcuk, https://github.com/nfc-tools/mfcuk
- Installed, because it has Mifare Classic DarkSide Key Recovery Tool. This is an advanced approach into cracking the encryption keys.
- mfoc, https://github.com/nfc-tools/mfoc
- offline nested attack by Nethemba
- This is the one, NXP tried to prevent the hack to be publicly released, see info from https://www.secureidnews.com/news-item/nxp-sues-to-prevent-hackers-from-releasing-mifare-flaws/
- Creating an own encryption algorithm and expecting nobody to figure out how it works will work for a very short period of time. Going to a judge to prevent the information from leaking also works... if you're high on something! But on real life it works never.
All of the above software was installed with ./configure --prefix=/usr/local/rfid to avoid breaking anything already installed into the system.
Running the tools
Basic information from the tag (the actual tag UID is omitted):
# nfc-list
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 11 22 33 44
SAK (SEL_RES): 08
ATQA 00, 04 is listed in ISO/IEC 14443 Type A generations and is identified as MIFARE Classic. Goody! It's weak and hackable.
Just running mfoc to see if a slow attack can proceed:
# mfoc -O card.dmp
Found Mifare Classic 1k tag
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID size: single
bit frame anticollision supported
UID (NFCID1): 11 22 33 44
SAK (SEL_RES): 08
Not compliant with ISO/IEC 14443-4
Not compliant with ISO/IEC 18092
Fingerprinting based on MIFARE type Identification Procedure:
MIFARE Classic 1K
MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation
And very soon, it results:
We have all sectors encrypted with the default keys..
Auth with all sectors succeeded, dumping keys to a file!
WHAAT! The card wasn't encrypted at all!
A closer look into card.dmp reveals, that there was no payload in the 1024 bytes this particular MIFARE Classic stored.
Since, the card doesn't have any payload, the application has to work based on childish assumption, that the UID of a RFID-tag cannot be changed. Nice! Because it can be set to whatever I want it to be! Like this:
# nfc-mfsetuid 11223344
NFC reader: ACS / ACR122U PICC Interface opened
Found tag with
UID: 01234567
ATQA: 0004
SAK: 08
My blank UID-writable tag had UID of 01 02 03 04, but I changed it into something else. Note: This is not allowed by the specs, but using very cheap eBay-hardware, obviously it can be done! Nice.
To verify my hack:
I walked into the appliation and used my clone successfully. Also, I informed the owners, that their security is ... well ... not secure. They shouldn't use UIDs as the only authentication mechanism. It's only 4 bytes and anybody in the world can use that 4-byte password. Using encrypted payload would make more sense, if MIFARE Classic wouldn't have a major security flaw in it's key generation algorithm.
This was one of the easiest hacks I've completed for years.
Toying around with RFID, tags has always been something I wanted to do, but never had the time. Contactless payment is gaining traction all around the world. The reason is very simple: it is fast and convenient for both the customer and vendor to just touch'n'go with your credit card or mobile phone on a point-of-sale.
Credit/Debit card payments are based on EMV, or Europay MasterCard and Visa, standard. See generic EMV info at https://en.wikipedia.org/wiki/EMV. Back in 2011 Visa started driving the contactless standard worldwide, and given the situation today, their efforts paid off. However, my understanding is, that at the time of writing this, regardless number of people attempting it, there are no known vulnerabilities in the contactless EMV. Finding one, would be sweet, but finding one would also be extremely hard and time consuming. So, I decided to go for something easier. MIFARE Classic.
What's this RFID, isn't it NFC?
Short answer: yes and no.
Long answer:
This infographic is courtesy of atlasRFIDstore
http://blog.atlasrfidstore.com/rfid-vs-nfc
MIFARE Classic info
Since this topic isn't especially new, I'm just posting some useful sites I found to be very useful when doing RFID-hacks:
- Finding the encryption keys:
- Cloning the tag:
- Information about Mifare Classic encryption key hacking:
- ISO/IEC 14443 Type A generations:
Going to eBay for the hardware
I had a real-world RFID -tag, and wanted to take a peek into it. For that to happen, I needed some hardware.
The choice for reader/writer is obvious, an ACR122. Info is at: https://www.acs.com.hk/en/products/3/acr122u-usb-nfc-reader/. The thing costs almost nothing and is extremely well supported by all kinds of hacking software.
Going to GitHub for the software
All the software needed in this project can be found from GitHub:
- libusb, https://github.com/libusb/libusb
- Some software want libusb 0.1 some 1.0. I had only 0.1 installed so I had to compile the latest also.
- libnfc, https://github.com/nfc-tools/libnfc
- Latest installed
- MiFare Classic Universal toolKit, mfcuk, https://github.com/nfc-tools/mfcuk
- Installed, because it has Mifare Classic DarkSide Key Recovery Tool. This is an advanced approach into cracking the encryption keys.
- mfoc, https://github.com/nfc-tools/mfoc
- offline nested attack by Nethemba
- This is the one, NXP tried to prevent the hack to be publicly released, see info from https://www.secureidnews.com/news-item/nxp-sues-to-prevent-hackers-from-releasing-mifare-flaws/
- Creating an own encryption algorithm and expecting nobody to figure out how it works will work for a very short period of time. Going to a judge to prevent the information from leaking also works... if you're high on something! But on real life it works never.
All of the above software was installed with ./configure --prefix=/usr/local/rfid to avoid breaking anything already installed into the system.
Running the tools
Basic information from the tag (the actual tag UID is omitted):
# nfc-list
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 11 22 33 44
SAK (SEL_RES): 08
ATQA 00, 04 is listed in ISO/IEC 14443 Type A generations and is identified as MIFARE Classic. Goody! It's weak and hackable.
Just running mfoc to see if a slow attack can proceed:
# mfoc -O card.dmp
Found Mifare Classic 1k tag
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID size: single
bit frame anticollision supported
UID (NFCID1): 11 22 33 44
SAK (SEL_RES): 08
Not compliant with ISO/IEC 14443-4
Not compliant with ISO/IEC 18092
Fingerprinting based on MIFARE type Identification Procedure:
MIFARE Classic 1K
MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation
And very soon, it results:
We have all sectors encrypted with the default keys..
Auth with all sectors succeeded, dumping keys to a file!
WHAAT! The card wasn't encrypted at all!
A closer look into card.dmp reveals, that there was no payload in the 1024 bytes this particular MIFARE Classic stored.
Since, the card doesn't have any payload, the application has to work based on childish assumption, that the UID of a RFID-tag cannot be changed. Nice! Because it can be set to whatever I want it to be! Like this:
# nfc-mfsetuid 11223344
NFC reader: ACS / ACR122U PICC Interface opened
Found tag with
UID: 01234567
ATQA: 0004
SAK: 08
My blank UID-writable tag had UID of 01 02 03 04, but I changed it into something else. Note: This is not allowed by the specs, but using very cheap eBay-hardware, obviously it can be done! Nice.
To verify my hack:
I walked into the appliation and used my clone successfully. Also, I informed the owners, that their security is ... well ... not secure. They shouldn't use UIDs as the only authentication mechanism. It's only 4 bytes and anybody in the world can use that 4-byte password. Using encrypted payload would make more sense, if MIFARE Classic wouldn't have a major security flaw in it's key generation algorithm.
This was one of the easiest hacks I've completed for years.
iPhone Mobile Profile for a new CA root certificate - Case CAcert.org
Friday, April 20. 2018
Year ago, I posted about CAcert root certificate being re-hashed with SHA-256 to comply with modern requirements. The obvious problem with that is, that it is not especially easy to install own certificates (or the new CAcert root) into a phone anymore.
When you try to access your mail server (or any other resource via HTTPS), the result will be something like this:
Not very cool. Getting the "Cannot Verify Server Identity" -error. This is especially bad, because in modern iOS you really don't have a clue how to get the new root cert installed and trusted. No worries! I can describe the generic process here.
Apple Configurator 2
Get it from https://itunes.apple.com/us/app/apple-configurator-2/id1037126344. Install it into your Mac. It doesn't cost anything, but will help you a lot!
If you dream on running it on a Windows/Linux/BSD, just briefly visit your nearest Mac-store and with your newly purchased Mac start over from the part "Get it from..."
Root certificate to be installed
Get a root certificate you want to distribute as trusted root CA. With the Apple Configurator 2, create a profile containing only one payload. The certificate in question.
This is what it would look like:
When that mobile profile is exported from Apple Configurator 2, you will get an unsigned .mobileconfig-file. That will work, but just give grievance during install-time about not being unsigned. If you can live with an extra notice, then just go to next step. If you cannot, get a real code-signing -certificate and sign your profile with that.
Publishing your .mobileconfig from a web server
Your precious .mobileconfig-doesn't just automatically fly into your iOS-device, you need to do some heavy lifting first.
On your favorite web-server, which can be accessed from your iOS-device and you can fully control, place the .mobileconfig-file there as a static resource and make it have content-type application/x-apple-aspen-config.
On Apache:
AddType application/x-apple-aspen-config .mobileconfig
On Nginx:
types {
application/x-apple-aspen-config mobileconfig;
}
Testing the content-type setting with curl:
# curl --verbose "https:...."
> User-Agent: curl/7.32.0
>
< HTTP/1.1 200 OK
< Content-Type: application/x-apple-aspen-config
Install the profile into your iOS-gadget
That's simple: just whip up Mobile Safari and surf to the URL. Given the correctly set content-type, it will launch profile installer:
During the process you will need to punch in your PIN-code (if you're using one in your device). There are way too many confirmations, if you really, really, for sure want to install that particular profile. The questions are there for a very good reason. A mobile profile can contain a combination of settings that will eventually either leave you powerless to control your own device, or alternatively allow remote control of your very own device. Or both. So, be very careful when installing those mobile profiles!
Finally
Now you have your new root certificate installed and trusted. Go test it!
For those who are very brave:
My recommendation is not to do this. Do not trust me or my published files!
I have published my own .mobileconfig into the web server of this blog. The address for the profile is:
https://blog.hqcodeshop.fi/CAcert/CAcert.org%20root%20CA%20profile.mobileconfig
I'll repeat: That is there for your reference only. Do not trust me for such a security-sensitive file.
Year ago, I posted about CAcert root certificate being re-hashed with SHA-256 to comply with modern requirements. The obvious problem with that is, that it is not especially easy to install own certificates (or the new CAcert root) into a phone anymore.
When you try to access your mail server (or any other resource via HTTPS), the result will be something like this:
Not very cool. Getting the "Cannot Verify Server Identity" -error. This is especially bad, because in modern iOS you really don't have a clue how to get the new root cert installed and trusted. No worries! I can describe the generic process here.
Apple Configurator 2
Get it from https://itunes.apple.com/us/app/apple-configurator-2/id1037126344. Install it into your Mac. It doesn't cost anything, but will help you a lot!
If you dream on running it on a Windows/Linux/BSD, just briefly visit your nearest Mac-store and with your newly purchased Mac start over from the part "Get it from..."
Root certificate to be installed
Get a root certificate you want to distribute as trusted root CA. With the Apple Configurator 2, create a profile containing only one payload. The certificate in question.
This is what it would look like:
When that mobile profile is exported from Apple Configurator 2, you will get an unsigned .mobileconfig-file. That will work, but just give grievance during install-time about not being unsigned. If you can live with an extra notice, then just go to next step. If you cannot, get a real code-signing -certificate and sign your profile with that.
Publishing your .mobileconfig from a web server
Your precious .mobileconfig-doesn't just automatically fly into your iOS-device, you need to do some heavy lifting first.
On your favorite web-server, which can be accessed from your iOS-device and you can fully control, place the .mobileconfig-file there as a static resource and make it have content-type application/x-apple-aspen-config.
On Apache:
AddType application/x-apple-aspen-config .mobileconfig
On Nginx:
types {
application/x-apple-aspen-config mobileconfig;
}
Testing the content-type setting with curl:
# curl --verbose "https:...."
> User-Agent: curl/7.32.0
>
< HTTP/1.1 200 OK
< Content-Type: application/x-apple-aspen-config
Install the profile into your iOS-gadget
That's simple: just whip up Mobile Safari and surf to the URL. Given the correctly set content-type, it will launch profile installer:
During the process you will need to punch in your PIN-code (if you're using one in your device). There are way too many confirmations, if you really, really, for sure want to install that particular profile. The questions are there for a very good reason. A mobile profile can contain a combination of settings that will eventually either leave you powerless to control your own device, or alternatively allow remote control of your very own device. Or both. So, be very careful when installing those mobile profiles!
Finally
Now you have your new root certificate installed and trusted. Go test it!
For those who are very brave:
My recommendation is not to do this. Do not trust me or my published files!
I have published my own .mobileconfig into the web server of this blog. The address for the profile is:
https://blog.hqcodeshop.fi/CAcert/CAcert.org%20root%20CA%20profile.mobileconfig
I'll repeat: That is there for your reference only. Do not trust me for such a security-sensitive file.
Replacing Symantec certificates
Monday, March 19. 2018
Little bit of background about having certificates
A quote from https://www.brightedge.com/blog/http-https-and-seo/:
Google called for “HTTPS Everywhere” (secure search) at its I/O conference in June 2014 with its Webmaster Trends Analyst Pierre Far stating: “We want to convince you that all communications should be secure by default”
So, anybody with any sense in their head have moved to having their website prefer HTTPS as the communication protocol. For that to happen, a SSL certificate is required. In practice any X.509 would do the trick of encryption, but anybody visiting your website would get all kinds of warnings about that. An excellent website having failing certificates is https://badssl.com/. The precise error for you would see having a randomly selected certificate can be demonstrated at https://untrusted-root.badssl.com/.
Google, as the industry leader, has taken a huge role in driving certificate business to a direction it seems fit. They're hosting the most used website (google.com, according to https://en.wikipedia.org/wiki/List_of_most_popular_websites) and the most used web browser (Chrome, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). So, when they say something, it has a major impact to the Internet.
What they have said, is to start using secured HTTP for communications. There is an entire web page by Google about Marking HTTP As Non-Secure, having the timeline of how every single website needs to use HTTPS or risk being undervalued by GoogleBot and being flagged as insecure to web browsing audience.
Little bit of background about what certificates do
Since people publishing their stuff to the Net, like me, don't want to be downvalued or flagged as insecure, having a certificate is kinda mandatory. And that's what I did. Couple years ago, in fact.
I have no interest in paying the huge bucks for the properly validated certificates, I simply went for the cheapest possible Domain Validated (DV) cert. All validation types are described in https://casecurity.org/2013/08/07/what-are-the-different-types-of-ssl-certificates/. The reasoning, why in my opinion, those different verification types are completely bogus can be found from my blog post from 2013, HTTP Secure: Is Internet really broken?. The quote from sslshopper.com is:
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."
Nowhere in the technical specifcation of certificates, you can find anything related to actually identifying the other party you're encrypting your traffic with. A X.509 certificate has attributes in it, which may suggest that the other party is who the certificate says to be, but's an assumption at best. There is simply no way of you KNOWING it. What the SSL certificate industry wants you to believe, is that they doing all kinds of expensive verification makes your communications more secure. In reality it's just smoke and mirrors, a hoax. Your communications are as well encrypted using the cheapest or most expensive certificate.
Example:
You can steal a SSL certificate from Google.com and set up your own website having that as your certificate. It doesn't make your website Google, even the certificate so suggests.
Little bit of background about Symantec failing to do certificates
Nobody from Symantec or its affiliates informed me about this. Given, that I follow security scene and bumped into news about a dispute between Google and Symantec. This article is from 2015 in The Register: Fuming Google tears Symantec a new one over rogue SSL certs. A quote from the article says:
On October 12, Symantec said they had found that another 164 rogue certificates had been issued
in 76 domains without permission, and 2,458 certificates were issued for domains that were never registered.
"It's obviously concerning that a certificate authority would have such a long-running issue
and that they would be unable to assess its scope after being alerted to it and conducting an audit,"
So, this isn't anything new here. This is what all those years of fighting resulted as: Replace Your Symantec SSL/TLS Certificates:
Near the end of July 2017, Google Chrome created a plan to first reduce and then remove trust (by showing security warnings in the Chrome browser) of all Symantec, Thawte, GeoTrust, and RapidSSL-issued SSL/TLS certificates.
And: 23,000 HTTPS certs will be axed in next 24 hours after private keys leak.
In short:
They really dropped the ball. First they issued 164 certificates, which nobody actually ordered from them. Those rogue certificates included one for google.com. Then they somehow "lost" 23k private keys for already issued certificates.
That's really unacceptable for a company by their own words is "Global Leader In Next-Generation Cyber Security". That's what Symantec website https://www.symantec.com/ says, still today.
What next?
Symantec has a website called Check your website for Chrome distrust at https://www.websecurity.symantec.com/support/ssl-checker.
I did check the cert of this blog, and yup. It flagged the certificate as one needing immediate replacement. The certificate details have:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
24:6f:ae:e0:bf:16:8d:e5:7a:13:fb:bd:1e:1f:8d:a1
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
Validity
Not Before: Nov 25 00:00:00 2017 GMT
Not After : Feb 23 23:59:59 2021 GMT
Subject: CN=blog.hqcodeshop.fi
That's a GeoTrust Inc. issued certificate. GeoTrust is a subsidiary of Symantec. I did study the history of Symantec' certificate business and back in 2010 they acquired Verisign's certificate business resulting as ownership of Thawte and GeoTrust. RapidSSL is the el-cheapo brand of GeoTrust.
As instructed, I just re-issued the existing certificate. It resulted in:
Now, my certificate traces back to a DigiCert CA root.
That's all good. I and you can continue browsing my blog without unnecessary this-website-is-not-secure -warnings.
Little bit of background about having certificates
A quote from https://www.brightedge.com/blog/http-https-and-seo/:
Google called for “HTTPS Everywhere” (secure search) at its I/O conference in June 2014 with its Webmaster Trends Analyst Pierre Far stating: “We want to convince you that all communications should be secure by default”
So, anybody with any sense in their head have moved to having their website prefer HTTPS as the communication protocol. For that to happen, a SSL certificate is required. In practice any X.509 would do the trick of encryption, but anybody visiting your website would get all kinds of warnings about that. An excellent website having failing certificates is https://badssl.com/. The precise error for you would see having a randomly selected certificate can be demonstrated at https://untrusted-root.badssl.com/.
Google, as the industry leader, has taken a huge role in driving certificate business to a direction it seems fit. They're hosting the most used website (google.com, according to https://en.wikipedia.org/wiki/List_of_most_popular_websites) and the most used web browser (Chrome, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). So, when they say something, it has a major impact to the Internet.
What they have said, is to start using secured HTTP for communications. There is an entire web page by Google about Marking HTTP As Non-Secure, having the timeline of how every single website needs to use HTTPS or risk being undervalued by GoogleBot and being flagged as insecure to web browsing audience.
Little bit of background about what certificates do
Since people publishing their stuff to the Net, like me, don't want to be downvalued or flagged as insecure, having a certificate is kinda mandatory. And that's what I did. Couple years ago, in fact.
I have no interest in paying the huge bucks for the properly validated certificates, I simply went for the cheapest possible Domain Validated (DV) cert. All validation types are described in https://casecurity.org/2013/08/07/what-are-the-different-types-of-ssl-certificates/. The reasoning, why in my opinion, those different verification types are completely bogus can be found from my blog post from 2013, HTTP Secure: Is Internet really broken?. The quote from sslshopper.com is:
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."
Nowhere in the technical specifcation of certificates, you can find anything related to actually identifying the other party you're encrypting your traffic with. A X.509 certificate has attributes in it, which may suggest that the other party is who the certificate says to be, but's an assumption at best. There is simply no way of you KNOWING it. What the SSL certificate industry wants you to believe, is that they doing all kinds of expensive verification makes your communications more secure. In reality it's just smoke and mirrors, a hoax. Your communications are as well encrypted using the cheapest or most expensive certificate.
Example:
You can steal a SSL certificate from Google.com and set up your own website having that as your certificate. It doesn't make your website Google, even the certificate so suggests.
Little bit of background about Symantec failing to do certificates
Nobody from Symantec or its affiliates informed me about this. Given, that I follow security scene and bumped into news about a dispute between Google and Symantec. This article is from 2015 in The Register: Fuming Google tears Symantec a new one over rogue SSL certs. A quote from the article says:
On October 12, Symantec said they had found that another 164 rogue certificates had been issued
in 76 domains without permission, and 2,458 certificates were issued for domains that were never registered.
"It's obviously concerning that a certificate authority would have such a long-running issue
and that they would be unable to assess its scope after being alerted to it and conducting an audit,"
So, this isn't anything new here. This is what all those years of fighting resulted as: Replace Your Symantec SSL/TLS Certificates:
Near the end of July 2017, Google Chrome created a plan to first reduce and then remove trust (by showing security warnings in the Chrome browser) of all Symantec, Thawte, GeoTrust, and RapidSSL-issued SSL/TLS certificates.
And: 23,000 HTTPS certs will be axed in next 24 hours after private keys leak.
In short:
They really dropped the ball. First they issued 164 certificates, which nobody actually ordered from them. Those rogue certificates included one for google.com. Then they somehow "lost" 23k private keys for already issued certificates.
That's really unacceptable for a company by their own words is "Global Leader In Next-Generation Cyber Security". That's what Symantec website https://www.symantec.com/ says, still today.
What next?
Symantec has a website called Check your website for Chrome distrust at https://www.websecurity.symantec.com/support/ssl-checker.
I did check the cert of this blog, and yup. It flagged the certificate as one needing immediate replacement. The certificate details have:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
24:6f:ae:e0:bf:16:8d:e5:7a:13:fb:bd:1e:1f:8d:a1
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
Validity
Not Before: Nov 25 00:00:00 2017 GMT
Not After : Feb 23 23:59:59 2021 GMT
Subject: CN=blog.hqcodeshop.fi
That's a GeoTrust Inc. issued certificate. GeoTrust is a subsidiary of Symantec. I did study the history of Symantec' certificate business and back in 2010 they acquired Verisign's certificate business resulting as ownership of Thawte and GeoTrust. RapidSSL is the el-cheapo brand of GeoTrust.
As instructed, I just re-issued the existing certificate. It resulted in:
Now, my certificate traces back to a DigiCert CA root.
That's all good. I and you can continue browsing my blog without unnecessary this-website-is-not-secure -warnings.
Microsoft Virtual Security Summit
Wednesday, March 14. 2018
I got and ad from Microsoft about a security summit they were organizing. Since it was virtual, I didn't have to travel anywhere and the agenda looked interesting, I signed up.
The screenshot has Jim Moeller and Michael Melone from Microsoft and the summit host Josephine Cheng.
Quotes:
Question:
What's worse then being a victim of a cyber crime?
Answer:
Not knowing about it.
- Shawn Anderson, Microsoft
"Security is not a product, it's a technique."
- Michael Melone, Microsoft
"It's kinda like outrunning a bear. I don't have to be the fastest person, I just have to be faster than Mike."
- Jim Moeller, Microsoft, about infosec referring to Michael Melone sitting next to him
"At the end of the day, these types of crimes are borderless"
- Patti Chrzan, Microsoft
Discussion points:
There were a number of professionals speaking in this three hour session. I saw these couple of themes popping up constantly:
- Security hygiene
- Run patches to make your stuff up-to-date
- Control user's access
- Invest into your security, to make attackers ROI low enough to attack somebody else
- Security is a team sport!
- Entire industry needs to share and participate
- Law enforcement globally needs to participate
- Attacks are getting more sophisticated.
- 90% of cybercrime start from a sophisticated phishing mail
- When breached, new malware can steal domain admin's credentials and infect secured machines also.
- Command & control traffic can utilize stolen user credentials and corporate VPN to pass trough firewall.
- Attackers are financially motivated.
- Ransomware
- Bitcoin mining
- Petaya/Notpetaya being an exception, it just caused massive destruction
- Identity is the perimeter to protect
- Things are in the cloud, there is no perimeter
- Is the person logging in really who he/she claims to be?
- Enabling 2-factor authentication is vital
Finally:
Was it worth spending 3 hours? Oh yes! There were mandatory commercials for Microsoft products, but getting the update from people who work in the security field daily was definitely valuable. Given my personal interest in the field, lot of the talks were targeted towards non-security professionals. However, the infosec professionals managed to keep the talks interesting enough with their fresh information directly from the trenches.
I got and ad from Microsoft about a security summit they were organizing. Since it was virtual, I didn't have to travel anywhere and the agenda looked interesting, I signed up.
Quotes:
- Michael Melone, Microsoft
- Jim Moeller, Microsoft, about infosec referring to Michael Melone sitting next to him
- Patti Chrzan, Microsoft
Discussion points:
- Security hygiene
- Run patches to make your stuff up-to-date
- Control user's access
- Invest into your security, to make attackers ROI low enough to attack somebody else
- Security is a team sport!
- Entire industry needs to share and participate
- Law enforcement globally needs to participate
- Attacks are getting more sophisticated.
- 90% of cybercrime start from a sophisticated phishing mail
- When breached, new malware can steal domain admin's credentials and infect secured machines also.
- Command & control traffic can utilize stolen user credentials and corporate VPN to pass trough firewall.
- Attackers are financially motivated.
- Ransomware
- Bitcoin mining
- Petaya/Notpetaya being an exception, it just caused massive destruction
- Identity is the perimeter to protect
- Things are in the cloud, there is no perimeter
- Is the person logging in really who he/she claims to be?
- Enabling 2-factor authentication is vital
Finally:
Goodbye CAcert.org - Welcome Let's Encrypt!
Sunday, March 11. 2018
A brief history of CAcert.org
For almost two decades, my primary source for non-public facing X.509 certificates has been CAcert.org. They were one of the first ever orgs handing out free-of-charge certificates to anybody who wanted one. Naturally, you had to pass a simple verification to prove that you actually could control the domain you were applying a certificate for. When you did that, you could issue certificates with multiple hostnames or even wildcard certificates. And all that costing nothing!
The obvious problem with CAcert.org always was, that they were not included in any of the major web browsers. Their inclusion list at https://wiki.cacert.org/InclusionStatus is a sad read. It doesn't even have Google Chrome, the most popular browser of current time in the list. The list simply hasn't been updated during the lifetime of Chrome! On a second thought looking it bit closer, the browser inclusion status -list is an accurate statement how CAcert.org is doing today. Not so good.
Wikipedia page https://en.wikipedia.org/wiki/CAcert.org has a brief history. Their root certificate was included in initial versions of Mozilla Firefox. When CA/Browser Forum was formed back in 2005 by some of the certificate business vendors of that time to have a set of rules and policies in place regarding web site certificates and the issuence policies, they kicked pretty much everybody out by default. Commerical vendors made the cut back in, but CAcert.org simply couldn't (or wouldn't) comply with those and withdrew their application for membership. The reson for CAcert.org not being able to act on anything is that the entire org is (and has been for a long time) pretty much dead. All the key persons are simply busy doing something else.
Today, the current status of CAcert.org is, that their certs are not trusted and signed by non-accepted hash algorithms. Over an year ago, there was a blip of activity and they managed to re-sign their root certificate with SHA-256, but to me it looks like they exhausted all the energy on the actual signing and newly signed root certs were never published. I wrote a post about how to actually get your hands on the new root certificate and install that to your machines.
Today, when CA/Browser Forum is mostly controlled by Google and Mozilla, a stalled CAcert.org would not be accepted as a member and at the same time there is huge pressure to start using properly signed and hashed certificates on all web traffic, I've run out of road with CAcert.org. So, for me, it's time to move on!
A brief history of Let's Encrypt
Two years ago, the certificate business had been hit hard. I collected a number of failures in my blog post about What's wrong with HTTPS. Roughly at the same time also Electronic Frontier Foundation (EFF) saw the situation as not acceptable. Businesses wanted serious money for their certs, but were not doing an especially good job about trustworthy business practices. With help of some major players (including Mozilla Foundation, Akamai Technologies, Cisco Systems, etc.) they created a non-profit organization for the sole purpose of issuing free-of-charge certificates to anybody who wanted one called Let's Encrypt.
They managed to pull that off, in a very short period of time, they become the most prominent certificate authority in the Internet. At least their product price is right, €0 for a cert. And you can request and get as many as you want to. There are some rate limits, so you cannot denial-of-service them, but for any practical uses, you can get all your certs from them. For free!
The practical benefit for Let's Encrypt operation is, that number of web server in The Net having HTTPS enabled has been rising. Both EFF and CA/Browser Forum is strongly suggesting, that all HTTP-traffic should be encrypted, aka. HTTPS. But the obvious hurdle in achieving that, is that everybody needs to have a certificate in their web server to enable encryption. Given Let's Encrypt, now everybody can do that! EFF has stated for long time, that having secure communications shouldn't be about money, it should be about your simply wanting to do that. The obvious next move is, that in coming years CAB Forum will announce, that all web traffic MUST be encrypted. However, we're not quite yet there.
Breifly on Let's Encrypt tech
Since they wanted to disrupt the certificate business, they abandoned current operation procedures. Their target is to run the entire request/issue-process fully automated and do that in a secure manner. To achieve that, they created a completely new protocol for Automatic Certificate Management Environment, or ACME. The RFC draft can be seen at https://datatracker.ietf.org/doc/draft-ietf-acme-acme/.
Their chain of trust (taken from https://letsencrypt.org/certificates/) is bit confusing to me:
As the root certificate, they use Digital Signature Trust Co. (red line with Identrust DST Root CA X3). That's something your browser has had for years. So, ultimately they didn't have to add anything. When you request a certificate, it is issued by the intermediate authority Let's Encrypt Authority X3. And as the bottom level is your very own Server Certificate.
However, I don't undertand why there is ISRG Root X1 to double-sign all the intermediates, and signing only their OCSP-data. My computers don't have that root certificate installed. So, what's the point of that?
As a note:
This is the recommened and typical way of setting up your certificate chain, nothing funny about that. For a layman, it will strike as overly complex, but in X.509-world things are done like that for security reasons and being able to "burn" an intermediate CA in a split second and roll forward to a new one without interruptions and need to install anything to your machines.
What the actual connection between Let's Encrypt and Digital Signature Trust Co. (IdenTrust) is unclear to me. If somebody knows, please drop a comment clarifying that.
My beef with Let's Encrypt
Short version: It's run by idiots! So, Let's not.
Long version:
- Tooling is seriously bad.
- The "official" python-based software won't work on any of my machines. And I don't want to try fixing their shit. I just let those pieces of crap rot.
- To me, Acme Inc. is heavily associated with Wile E Coyote
- Mr. Coyote never managed to catch the Road Runners. Many times it was because the Acme Inc. manufactured equipment failed to function. https://en.wikipedia.org/wiki/Acme_Corporation
- Did I mention about the bad tools?
- Every single tool I've ever laid my hands on wants to mess up my Apache and/or Nginx configuration.
- I have a very simple rule about my configurations: DON'T TOUCH THEM! If you want to touch them, ask me first (at which point I can reject the request).
- There seems to be no feasible way of running those crappy tools without them trying to break my configs first.
- Most 3rd-party written libraries are really bad
- There are libraries/tools for all imaginable programming languages implementing parts/all of ACME-protocol.
- Every single one of them are either bad or worse.
- Certificate life-span i 90 days. That's three (3) months!
- The disruptive concept behind this is, that you need to renew your certs every 60 days (or at max 90 days). For that to happen, you will need to learn automation. Noble thought, that. Not so easy to implement for all possible usages. The good thing is, that if ever achieved, you won't have to suffer from certificates expiring without you knowing about it.
- As an alternative, you can get a completely free-of-charge SSL certificate from Comodo, a member of Let's Encrypt, which is valid for 90 days, but you have to do it manually using Comodo's web GUI. See: https://ssl.comodo.com/free-ssl-certificate.php if you want one.
- I won't list those commercial CAs who can issue you a 30 day trial certificate for free here, because the list is too long. So, if you just want a short-lived cert, you have been able to that for a long time.
- They're not able to issue wildcard certificates, yet.
- This is on the works, so mentioning this is hitting them below the belt. Sorry about that.
- From their test-API, you can get a wildcard certificate, if you really, really, really need one. It won't be trusted by your browser, but it will be a real wildcard cert.
- Original release date for ACME v2 API in production was 27th Feb 2018, but for <insert explanation here> they were unable to make their own deadline. New schedule is during Q1/2018. See the Upcoming Features -page for details.
My solution
It's obvious, that I need to ditch the CAcert.org and the only viable one is Let's Encrypt (run by idiots). To make this bitter choice work for me, after evaluating a number of solutions, I found a reasonable/acceptable tool called acme.sh. This tool is written with Bash and it uses curl for the ACME access. The author publishes the entire package in Github, and I have my own fork of that, which doesn't have a line of code even thinking about touching my web server configurations. You can get that at https://github.com/HQJaTu/acme.sh
Since I love Rackspace for their cloud DNS. I even wrote a Rackspace API Cloud DNS -plugin for acme.sh to make my automated certificate renewals work seamlessly. After carefully removing all other options for domain verification, it is 100% obvious, that I will do all of my ACME domain verifications only via DNS. Actually, for wildcard certs, it is the only allowed approach. Also, some of the certificates I'm using are for appliance, which I carefully firewall out of the wild wild web. Those ridiculous web site verification wouldn't work for me anyway.
And for those, who are wondering, Why Rackspace Cloud DNS? The answer is simple: price. They charge for $0/domain. That is unlike most cloud/DNS service providers, who want actual money for their service. With Rackspace you'll get premium GUI, premium API, premium anycast DNS servers with the right price, free-of-charge. You will need to enter a valid credit card when you create the account, but as they state: they won't charge it unless you subscribe to a paid service. I've been running their DNS for years, and they never charged me once. (If they see this blog post, they probably will!)
What I'm anxiously waiting is the ACME v2 API release, which is due any day now. That will allow me to get my precious wildcard certificates using these new scripts.
Now that my chips are in, its just me converting my systems to use the Wile E Coyote stuff for getting/renewing certs. And I will need to add tons of automation with Bash, Perl, Ansible, Saltstack, ... whatever to keep the actual servers running as intened. Most probably, I will post some of my automations in this blog. Stay tuned for those!
A brief history of CAcert.org
For almost two decades, my primary source for non-public facing X.509 certificates has been CAcert.org. They were one of the first ever orgs handing out free-of-charge certificates to anybody who wanted one. Naturally, you had to pass a simple verification to prove that you actually could control the domain you were applying a certificate for. When you did that, you could issue certificates with multiple hostnames or even wildcard certificates. And all that costing nothing!
The obvious problem with CAcert.org always was, that they were not included in any of the major web browsers. Their inclusion list at https://wiki.cacert.org/InclusionStatus is a sad read. It doesn't even have Google Chrome, the most popular browser of current time in the list. The list simply hasn't been updated during the lifetime of Chrome! On a second thought looking it bit closer, the browser inclusion status -list is an accurate statement how CAcert.org is doing today. Not so good.
Wikipedia page https://en.wikipedia.org/wiki/CAcert.org has a brief history. Their root certificate was included in initial versions of Mozilla Firefox. When CA/Browser Forum was formed back in 2005 by some of the certificate business vendors of that time to have a set of rules and policies in place regarding web site certificates and the issuence policies, they kicked pretty much everybody out by default. Commerical vendors made the cut back in, but CAcert.org simply couldn't (or wouldn't) comply with those and withdrew their application for membership. The reson for CAcert.org not being able to act on anything is that the entire org is (and has been for a long time) pretty much dead. All the key persons are simply busy doing something else.
Today, the current status of CAcert.org is, that their certs are not trusted and signed by non-accepted hash algorithms. Over an year ago, there was a blip of activity and they managed to re-sign their root certificate with SHA-256, but to me it looks like they exhausted all the energy on the actual signing and newly signed root certs were never published. I wrote a post about how to actually get your hands on the new root certificate and install that to your machines.
Today, when CA/Browser Forum is mostly controlled by Google and Mozilla, a stalled CAcert.org would not be accepted as a member and at the same time there is huge pressure to start using properly signed and hashed certificates on all web traffic, I've run out of road with CAcert.org. So, for me, it's time to move on!
A brief history of Let's Encrypt
Two years ago, the certificate business had been hit hard. I collected a number of failures in my blog post about What's wrong with HTTPS. Roughly at the same time also Electronic Frontier Foundation (EFF) saw the situation as not acceptable. Businesses wanted serious money for their certs, but were not doing an especially good job about trustworthy business practices. With help of some major players (including Mozilla Foundation, Akamai Technologies, Cisco Systems, etc.) they created a non-profit organization for the sole purpose of issuing free-of-charge certificates to anybody who wanted one called Let's Encrypt.
They managed to pull that off, in a very short period of time, they become the most prominent certificate authority in the Internet. At least their product price is right, €0 for a cert. And you can request and get as many as you want to. There are some rate limits, so you cannot denial-of-service them, but for any practical uses, you can get all your certs from them. For free!
The practical benefit for Let's Encrypt operation is, that number of web server in The Net having HTTPS enabled has been rising. Both EFF and CA/Browser Forum is strongly suggesting, that all HTTP-traffic should be encrypted, aka. HTTPS. But the obvious hurdle in achieving that, is that everybody needs to have a certificate in their web server to enable encryption. Given Let's Encrypt, now everybody can do that! EFF has stated for long time, that having secure communications shouldn't be about money, it should be about your simply wanting to do that. The obvious next move is, that in coming years CAB Forum will announce, that all web traffic MUST be encrypted. However, we're not quite yet there.
Breifly on Let's Encrypt tech
Since they wanted to disrupt the certificate business, they abandoned current operation procedures. Their target is to run the entire request/issue-process fully automated and do that in a secure manner. To achieve that, they created a completely new protocol for Automatic Certificate Management Environment, or ACME. The RFC draft can be seen at https://datatracker.ietf.org/doc/draft-ietf-acme-acme/.
Their chain of trust (taken from https://letsencrypt.org/certificates/) is bit confusing to me:
As the root certificate, they use Digital Signature Trust Co. (red line with Identrust DST Root CA X3). That's something your browser has had for years. So, ultimately they didn't have to add anything. When you request a certificate, it is issued by the intermediate authority Let's Encrypt Authority X3. And as the bottom level is your very own Server Certificate.
However, I don't undertand why there is ISRG Root X1 to double-sign all the intermediates, and signing only their OCSP-data. My computers don't have that root certificate installed. So, what's the point of that?
As a note:
This is the recommened and typical way of setting up your certificate chain, nothing funny about that. For a layman, it will strike as overly complex, but in X.509-world things are done like that for security reasons and being able to "burn" an intermediate CA in a split second and roll forward to a new one without interruptions and need to install anything to your machines.
What the actual connection between Let's Encrypt and Digital Signature Trust Co. (IdenTrust) is unclear to me. If somebody knows, please drop a comment clarifying that.
My beef with Let's Encrypt
Short version: It's run by idiots! So, Let's not.
Long version:
- Tooling is seriously bad.
- The "official" python-based software won't work on any of my machines. And I don't want to try fixing their shit. I just let those pieces of crap rot.
- To me, Acme Inc. is heavily associated with Wile E Coyote
- Mr. Coyote never managed to catch the Road Runners. Many times it was because the Acme Inc. manufactured equipment failed to function. https://en.wikipedia.org/wiki/Acme_Corporation
- Mr. Coyote never managed to catch the Road Runners. Many times it was because the Acme Inc. manufactured equipment failed to function. https://en.wikipedia.org/wiki/Acme_Corporation
- Did I mention about the bad tools?
- Every single tool I've ever laid my hands on wants to mess up my Apache and/or Nginx configuration.
- I have a very simple rule about my configurations: DON'T TOUCH THEM! If you want to touch them, ask me first (at which point I can reject the request).
- There seems to be no feasible way of running those crappy tools without them trying to break my configs first.
- Most 3rd-party written libraries are really bad
- There are libraries/tools for all imaginable programming languages implementing parts/all of ACME-protocol.
- Every single one of them are either bad or worse.
- Certificate life-span i 90 days. That's three (3) months!
- The disruptive concept behind this is, that you need to renew your certs every 60 days (or at max 90 days). For that to happen, you will need to learn automation. Noble thought, that. Not so easy to implement for all possible usages. The good thing is, that if ever achieved, you won't have to suffer from certificates expiring without you knowing about it.
- As an alternative, you can get a completely free-of-charge SSL certificate from Comodo, a member of Let's Encrypt, which is valid for 90 days, but you have to do it manually using Comodo's web GUI. See: https://ssl.comodo.com/free-ssl-certificate.php if you want one.
- I won't list those commercial CAs who can issue you a 30 day trial certificate for free here, because the list is too long. So, if you just want a short-lived cert, you have been able to that for a long time.
- They're not able to issue wildcard certificates, yet.
- This is on the works, so mentioning this is hitting them below the belt. Sorry about that.
- From their test-API, you can get a wildcard certificate, if you really, really, really need one. It won't be trusted by your browser, but it will be a real wildcard cert.
- Original release date for ACME v2 API in production was 27th Feb 2018, but for <insert explanation here> they were unable to make their own deadline. New schedule is during Q1/2018. See the Upcoming Features -page for details.
My solution
It's obvious, that I need to ditch the CAcert.org and the only viable one is Let's Encrypt (run by idiots). To make this bitter choice work for me, after evaluating a number of solutions, I found a reasonable/acceptable tool called acme.sh. This tool is written with Bash and it uses curl for the ACME access. The author publishes the entire package in Github, and I have my own fork of that, which doesn't have a line of code even thinking about touching my web server configurations. You can get that at https://github.com/HQJaTu/acme.sh
Since I love Rackspace for their cloud DNS. I even wrote a Rackspace API Cloud DNS -plugin for acme.sh to make my automated certificate renewals work seamlessly. After carefully removing all other options for domain verification, it is 100% obvious, that I will do all of my ACME domain verifications only via DNS. Actually, for wildcard certs, it is the only allowed approach. Also, some of the certificates I'm using are for appliance, which I carefully firewall out of the wild wild web. Those ridiculous web site verification wouldn't work for me anyway.
And for those, who are wondering, Why Rackspace Cloud DNS? The answer is simple: price. They charge for $0/domain. That is unlike most cloud/DNS service providers, who want actual money for their service. With Rackspace you'll get premium GUI, premium API, premium anycast DNS servers with the right price, free-of-charge. You will need to enter a valid credit card when you create the account, but as they state: they won't charge it unless you subscribe to a paid service. I've been running their DNS for years, and they never charged me once. (If they see this blog post, they probably will!)
What I'm anxiously waiting is the ACME v2 API release, which is due any day now. That will allow me to get my precious wildcard certificates using these new scripts.
Now that my chips are in, its just me converting my systems to use the Wile E Coyote stuff for getting/renewing certs. And I will need to add tons of automation with Bash, Perl, Ansible, Saltstack, ... whatever to keep the actual servers running as intened. Most probably, I will post some of my automations in this blog. Stay tuned for those!
