Is HTTPS Dangerous? HTTPS is incredibly useful but there may be critical flaws making it dangerous

By: ( +David Herron; Date: February 26, 2018

Tags: Security

HTTPS encrypts our website connections and it authenticates website identity. Both are excellent reassurances for website users, to give us a feeling of safety online. The video attached here makes a bold claim that HTTPS is actually dangerous. Let's take a look at that claim.

The video (see below) makes several claims.

Claim Real Discussion
Must be renewed Inconvenient SSL Certificates must expire, therefore the real issue is the manual process
Fake certificates Not quite Generally the process for validating SSL certificates is robust, but bugs exist everywhere and in a few cases bogus SSL certificates have been issued
NSA hashing algorithms Tin Foil Hat The NSA and other USA Government agencies developed critical algorithms for these uses, and possibly put in back-doors
Complex=vulnerable Maybe Hard to say for real

TL;DR The guy doing this video is one I've often thought makes big mountains out of small molehills. In this case he shows some information saying the NSA developed several of the algorithms behind HTTPS, and therefore the NSA can snoop HTTPS traffic, and therefore the HTTPS cannot satisfy the whole purpose for which it was developed.

There's enough of a grain of truth to that to be concerned. But not to the degree this guy says.

HTTPS/SSL certificates must be renewed

Problem: Because certificates are manually renewed, a website owner can forget to renew the site, or the website owner can stop maintaining the site, and the site will appear to be dangerous even when it's providing useful information. Sites with expired certificates are flagged by web browsers as risky. But what if it's a perfectly safe site just with an expired certificate?

The certificates do need to expire, the problem is the manual renewal process.

Most certificate authorities do not have an automated process of certificate renewal. Since website maintainers are forced to use manual processes, they can forget to renew the certificate one year and have an embarrassing couple of days scrambling to fix the problem.

Some certificate authorities do offer automated certificate renewal.

I've posted a tutorial showing how to automate Let's Encrypt certificate renewal in a Docker container: Deploying an Express app with HTTPS support in Docker using Lets Encrypt SSL

Fake certificates

Problem: Supposedly it's easy to create a fake SSL certificate and therefore have a fake unvalidated HTTPS setup.

I don't understand this claim unless it's the following.

It's easy to create self-signed certificates that aren't validated by higher authorities. Such a self-created self-signed certificate can say anything you want it to say, including claiming to be the SSL certificate for

The PKI infrastructure used for legitimate HTTPS/SSL certificates relies on a hierarchy of certificate authorities. The browser makers have a list of trusted Root CA's and any certificate issued by a CA certified by one of those Root CA's is deemed to be trustable.

But - that doesn't stop someone from using a self-signed certificate on their HTTPS website. If they do the browser will notice it's not certified by a trusted Root CA, and put up a big warning to the user.

But - what if a legitimate trusted CA can be tricked into producing a certificate for another website, like

But - what if some hacks into a legitimate trusted CA forcing it to produce bogus certificates?

In the case of a bogus certificate signed by trusted CA - someone could stand up a website claiming to be the site named in the bogus certificate.

This happened in 2011 when DigiNotar was hacked: (

In 2014, Netcraft said they found dozens of fake SSL certificates masquerading as real websites. (

The Netcraft article also talks of bugs in SSL validation libraries. An inegnious attacker might craft a bogus certificate that exploits such a flaw letting it look legitimate.

In 2013, Google announced having detected fake SSL certificates issued by an "Intermediate CA", ANSSI. Those fake certificates claimed authenticity over several Google domains. Google automatically made changes to the SSL certificate validation algorithms in Google Chrome, then warned the other browser makers of the problem. After some time, Google changed what they did to allow ANSSI certificates from certain domains, but not from others. (

In 2017, Google announced it would "distrust" certificates issued by Chinese CA's WoSign and StartCom. (

In 2015 it was discovered that Symantec had issued "Extended Validation" (EV) certificates for some Google domains, and that on further auditing found the company had issued thousands of bogus SSL certificates. In 2017, Google and other browser makers announced a plan to completely "distrust" Symantec's CA operation. (,33973.html

Symantec and its resellers are responsible for 1/3rd of the Web's SSL certificates, so that's a big step to take. ( And

Secure Hash Algorithm (SHA) developed by the NSA

Problem: HTTPS relies on SHA-1 in several ways. That algorithm was developed by the NSA. The same NSA that has been illegally breaking into computers all over the world, even inside the USA, so that NSA spies can spy on everything.

Given what's been revealed about the NSA how can we trust that the NSA did not install a backdoor via the critical algorithms?

In part the purpose for adopting HTTPS everywhere is so that NOBODY (including the NSA) can eavesdrop on our Internet connections. But, the NSA designed critical algorithms and presumably designed-in a backdoor.

By the way, a designed-in backdoor can be found by a miscreant. Especially since NSA's own hacking toolkit got stolen and released on the Internet.

SHA-2, also developed by the NSA, meant to be used in replacement of SHA-1.

SHA-3, another alternative, was developed by NIST which is technically part of the Commerce Department. But we can assume complicity with the NSA. Especially as NIST was required by law to cooperate with NSA.

SP800-90A is a Recommendation for Random Number Generation using Deterministic Random Number Generators. Encryption algorithms require random numbers but computers aren't capable of generating properly random numbers. Instead they're faked using algorithms that produce pseudo-random numbers. Which is a security issue because it makes encryption keys somewhat predictable.

More complexity means more vulnerabilities

Problem: The more complex a system, the more potential for breakages. That truism seems very real.

Does it mean HTTPS, by being more complex than HTTP, is more vulnerable? It's hard to say this claim is actual in the case of HTTPS.

« Did any parallel universe appear in Doctor Who? Udemy caught selling a Python programming course with stolen content »
2016 Election 2018 Elections Acer C720 Ad block Air Filters Air Quality Air Quality Monitoring AkashaCMS Amazon Amazon Kindle Amazon Web Services America Amiga and Jon Pertwee Android Anti-Fascism AntiVirus Software Apple Apple Hardware History Apple iPhone Apple iPhone Hardware April 1st Arduino ARM Compilation Artificial Intelligence Astronomy Astrophotography Asynchronous Programming Authoritarianism Automated Social Posting AWS DynamoDB AWS Lambda Ayo.JS Bells Law Big Brother Big Data Big Finish Big Science Bitcoin Mining Black Holes Blade Runner Blockchain Blogger Blogging Books Botnets Cassette Tapes Cellphones China China Manufacturing Christopher Eccleston Chrome Chrome Apps Chromebook Chromebox ChromeOS CIA CitiCards Citizen Journalism Civil Liberties Climate Change Clinton Cluster Computing Command Line Tools Comment Systems Computer Accessories Computer Hardware Computer Repair Computers Conservatives Cross Compilation Crouton Cryptocurrency Curiosity Rover Currencies Cyber Security Cybermen Cybersecurity Daleks Darth Vader Data backup Data Formats Data Storage Database Database Backup Databases David Tenant DDoS Botnet Department of Defense Department of Justice Detect Adblocker Developers Editors Digital Nomad Digital Photography Diskless Booting Disqus DIY DIY Repair DNP3 Do it yourself Docker Docker MAMP Docker Swarm Doctor Who Doctor Who Paradox Doctor Who Review Drobo Drupal Drupal Themes DVD E-Books E-Readers Early Computers eGPU Election Hacks Electric Bicycles Electric Vehicles Electron Eliminating Jobs for Human Emdebian Encabulators Energy Efficiency Enterprise Node EPUB ESP8266 Ethical Curation Eurovision Event Driven Asynchronous Express Face Recognition Facebook Fake News Fedora VirtualBox Fifth Doctor File transfer without iTunes FireFly Flash Flickr Fraud Freedom of Speech Front-end Development G Suite Gallifrey Gig Economy git Github GitKraken Gitlab GMAIL Google Google Chrome Google Gnome Google+ Government Spying Great Britain Green Transportation Hate Speech Heat Loss Hibernate High Technology Hoax Science Home Automation HTTP Security HTTPS Human ID I2C Protocol Image Analysis Image Conversion Image Processing ImageMagick In-memory Computing InfluxDB Infrared Thermometers Insulation Internet Internet Advertising Internet Law Internet of Things Internet Policy Internet Privacy iOS iOS Devices iPad iPhone iPhone hacking Iron Man iShowU Audio Capture iTunes Janet Fielding Java JavaFX JavaScript JavaScript Injection JDBC John Simms Journalism Joyent Kaspersky Labs Kext Kindle Kindle Marketplace Large Hadron Collider Lets Encrypt LibreOffice Linux Linux Hints Linux Single Board Computers Logging Mac Mini Mac OS Mac OS X MacBook Pro Machine Learning Machine Readable ID Macintosh macOS macOS High Sierra macOS Kext MacOS X setup Make Money Online Make Money with Gigs March For Our Lives MariaDB Mars Mass Violence Matt Lucas MEADS Anti-Missile Mercurial MERN Stack Michele Gomez Micro Apartments Microsoft Military AI Military Hardware Minification Minimized CSS Minimized HTML Minimized JavaScript Missy Mobile Applications Mobile Computers MODBUS Mondas Monetary System MongoDB Mongoose Monty Python MQTT Music Player Music Streaming MySQL NanoPi Nardole NASA Net Neutrality Network Attached Storage Node Web Development Node.js Node.js Database Node.js Performance Node.js Testing Node.JS Web Development Node.x North Korea npm NVIDIA NY Times Online advertising Online Community Online Fraud Online Journalism Online Photography Online Video Open Media Vault Open Source Open Source and Patents Open Source Governance Open Source Licenses Open Source Software OpenAPI OpenJDK OpenVPN Palmtop PDA Patrick Troughton PayPal Paywalls Personal Flight Peter Capaldi Peter Davison Phishing Photography PHP Plex Plex Media Server Political Protest Politics Postal Service Power Control President Trump Privacy Private E-mail server Production use Public Violence Raspberry Pi Raspberry Pi 3 Raspberry Pi Zero ReactJS Recaptcha Recycling Refurbished Computers Remote Desktop Removable Storage Republicans Retro Computing Retro-Technology Reviews RFID Rich Internet Applications Right to Repair River Song Robotics Robots Rocket Ships RSS News Readers rsync Russia Russia Troll Factory Russian Hacking Rust SCADA Scheme Science Fiction SD Cards Search Engine Ranking Season 1 Season 10 Season 11 Security Security Cameras Server-side JavaScript Serverless Framework Servers Shell Scripts Silence Simsimi Skype SmugMug Social Media Social Media Networks Social Media Warfare Social Network Management Social Networks Software Development Software Patents Space Flight Space Ship Reuse Space Ships SpaceX Spear Phishing Spring Spring Boot Spy Satellites SQLite3 SSD Drives SSD upgrade SSH SSH Key SSL Stand For Truth Strange Parts Swagger Synchronizing Files Tegan Jovanka Telescopes Terrorism The Cybermen The Daleks The Master Time-Series Database Tom Baker Torchwood Total Information Awareness Trump Trump Administration Trump Campaign Twitter Ubuntu Udemy UDOO US Department of Defense Video editing Virtual Private Networks VirtualBox VLC VNC VOIP Vue.js Walmart Weapons Systems Web Applications Web Developer Resources Web Development Web Development Tools Web Marketing Webpack Website Advertising Weeping Angels WhatsApp William Hartnell Window Insulation Windows Windows Alternatives Wordpress World Wide Web Yahoo YouTube YouTube Monetization