History

We had for years had the option for customers to go to HTTPS.

We offered it as a 'low cost' option on our hosted servers to those that requested – but interestingly, no one was willing to pay even the $100 we offered on one of our servers – and that didn't even recover our costs of doing it!

For a variety of reasons, in late 2015 we started converting all sites on the internet over to HTTPS

In December 2015 Chrome started to TAKE AWAY features that we used and only permit them on 'secure' connections where secure means: HTTPS or internal network only.

In 2016 a couple more features were removed from the 'non-secure' and required HTTPS.

Current (2016.12)

We expect, based on reports from browser authors, that in 2017 more that MCe uses will go away and some might even directly affect MRO in 2017.

There is a lawsuit in the USA by CryptoPeak Solutions by what some are calling a patent troll that may make payments due by those who have their data/websites using HTTPS. In September 2016 a motion to dismiss was denied.

This means, if you are running your own server, you will have to decide whether you want to use HTTPS or not based on that. But more and more, it will be impossible to operate with HTTP over the internet.

WHY would anyone use HTTPS?

Browsers are starting to show warnings if you don't use HTTPS. So one reason is to stop having users see the browser warnings.

Some features (like accessing the camera for barcode reading) are only permitted or made easier with HTTPS.

With HTTPS it is very unlikely than in the next decade anyone will be able to decode your transmissions, and as it becomes possible to decode them, there will be newer ways to decrypt that will make it more difficult to decrypt new transmissions.

HTTPS makes it much harder for evil people to 'inject' code (man in the middle attack) in the HTML you receive. Man in the middle attacks can do things like trick you into providing your login and passwords, trick you into installing viruses.

What are GOOD reasons to NOT install HTTPS?

If you have an internal server that is not providing data over the internet. And yes, that is the only good reason I know of. The issue here is that it is very hard to impossible to get an HTTPS certificate for that environment. And fortunately, so far at least, the browser manufacturers understand this and accept this as 'secure', or one step below secure, and haven't (to our knowledge) taken away any features like they have for 'over the internet' HTTP.

Reasons to not 'bother' using HTTPS that do not (no longer) make sense.

Ignoring the current (2015 December) patent case going on – and may go on for years:

Obviously there is a slight overhead in performance using HTTPS. But to be completely realistic, compared to 2000, the overhead is very close to zero. This is therefore no longer a valid reason. Back in the early days, yes, HTTPS was much slower and that was a good reason to ignore HTTPS unless you really needed it, but that was then, that's not with today's computers. Basically the power required to convert has not materially changed, but everything else around it has!

Side note: back in the old days

But it costs SO much to get HTTPS. A few years ago, sure. Today: You can get large multi-site ones from letsencrypt.org for free.

They are so hard to install: Some still are, but letsencrypt's are much easier than most 'competitors' were a few years ago.

HTTPS encryption is good now … but what about if someone stores my transmissions and decrypts them in say 10 years?

First of all – even if this happens, remember that HTTPS is better than HTTP. So you might as well use HTTPS for the security it provides.

But, since this is an expressed concern by some:

The NSA in the US is reported to be sniffing out billions of pieces of HTTPS data per hour and storing them in their computers. My understanding of their goal is that, by around 2025, computers will be SO much faster that they will be able to go back and un-encrypt all the data they saw go through the internet today. The idea being that things that currently would take current computers billions (using the 1,000,000,000 North American definition of billions) of years then taking only hours.

Is this realistic? It's mind boggling – but yes it is with the range of realistic, maybe even 'likely'. On December 9th 2015, it was reported that initial testing of a Google/NASA quantum computer made their test programs run literally more than 100 million times faster than a then typical modern desktop PC. That's 10,000,000,000 times faster. And given the theory of quantum computer, it is not unrealistic to think that that could become billions or literally trillions of times faster in the next 10 years. With numbers this large, I don't care which definition of billion or trillion you use! And decryption is listed as one of the best things for quantum computers. So if on current computers it would take a billion years, it is feasible that in 15 years it could take literally fractions of a second to decrypt. This means that something that would currently take billions of years to do on the fastest computers currently available in stores today might realistically take a fraction of a second to do on computers from your local computer store 20 years from now.

10 years ago SHA1 encryption was thought to be impossible (take millions of years to decrypt with the computers of those days) yet in 2015 it was shown that the NSA's computers were powerful enough to crack SHA1 encryption – this is one of the reason that no one offers SHA1 certificates anymore.

A little mind boggling isn't it!

So the conclusion some people make is: Why go through the hassle of using HTTPS if my transmissions will be decrypted in 10 years anyway? My answers are:

• there is no guarantee that the computers WILL be able to decrypt it in 10 years, it may take 15 or 20 or more.
• only what was stored can be decrypted – so do you really care if the NSA can decrypt it in that time? Very few other – even government – organizations could store that much data for 10+ years. So the chances of your transmissions being stored by anyone who can harm you (unless you are doing something so illegal that the NSA can 'harm' you) is very slim.
• most of your sensitive data today won't matter if someone sees it anyway. And if you are worried, if it is going to be transmitted, HTTPS today is your safest option.
• isn't having it protected/secured for about 10 years worth the tiny effort? And as computer power goes up, the encryptions will get better and we'll use it as it becomes commonly available.

So what do we recommend?

We now recommend you seriously consider the use of HTTPS, specifically the modern version which is HTTPS/TLS using SHA-2. (So the newest version, TLS 1.2 minimum) See also Terminology below, most people incorrectly refer to this as HTTPS-SSL/TLS.

Our hosted servers are already converted.

We consider it 'mandatory' for all new customers on the internet.

The following link has some good information on why we didn't use/recommend HTTPS prior to 2016 and why we do recommend it now. https://youtu.be/0JioB7rNpvI

Rational

There are several reasons why we do this now and why we didn't 'strongly encourage' it and why we didn't previously offer it 'for free' as part of our hosting service.

• Let's Encrypt has made, HTTPS very practical and easy to manage and ' free'.
  • The process is much simpler than the traditional ways of getting and renewing HTTPS
  • It's free. (This is more significant once you understand that the security advice is to purchase a new certificate ever x weeks or months so that you never have 'stale' certificates after things like the heartbleed virus. Following this advice prior to 2016 meant that you would be looking at thousands of dollars per year PER sub-domain. And given none of our customers were willing to pay even a small fee per month for HTTPS – following the best practices for HTTPS was impractical.)
• As 'flaws' are found in software, these two factors above mean you can have short term HTTPS licenses that don't perpetuate flaws (like happened when the heart bleed virus as going around.)Browsers are getting more and more obnoxious about sites that don't use HTTPS and some major browser vendors are promising to keep going in that direction until everyone is irritated enough to make the move.
• Previous certificates were mostly SHA1 which in 2015 was found to be 'reasonable' for someone like NSA to decrypt. The cost in time and effort, and the older browsers in use out there simply make SHA2 either difficult or impossible.

Reasons to use HTTPS with SHA-2:

• To keep passwords etc.., secret on the internet
• To stop intermediary sites (such as your user's Internet connection service providers) adding ads etc.., to your page. The MITM (Man In The Middle) scenario – both benign like hopefully your service provider is, and dangerous – like people writing phishing injections.

Reasons people give to do EVERYTHING HTTPS, not just pages with secure data

• A network adversary can rewrite links on the page so that even if the payment pages are HTTPS, a user would be tricked into going to a non-HTTPS version (or a fake site).
  • A comparatively low-effort version of this is automated SSL stripping, described by Moxie Marlinspike.
  • http://www.thoughtcrime.org/software/sslstrip/
• Bruce Schneier "urges people to 'make surveillance expensive again' by encrypting as much Internet data as possible…Every time you use encryption, you're protecting someone who needs to use it to stay alive." (my emphasis) He gives details explaining why he feels this is the case – and I essentially agree with his arguments.
• Some people don't like having corporations like Google following them and 'learning' about them to make decisions based on what they see you doing on the internet. Personally I don't mind this one, but I know more people do than don't so I'm willing to 'help them out'.

Limitations

What it won't prevent:

• Phishing (fake sites getting you to type in your id/password). The LoginHub 1 click does help with that because they know they never have to do this so the users will be more suspicious when asked. BUT … HTTPS will stop phishing in cases like where someone added a 'login' button into the Google Apps home page which is a phishing INJECTION.
• People who have access to your database directly (sys-admins, db admins, users with high security in your application(s) etc..,) Some reports suggest that over 80% of data theft is by people with high level access in the organization.

Terminology

I am giving 'practical' definitions of each of these terms, I am aware that technically the definition of most of these is a little more complicated. But the purpose here is to give a simple, practical, understanding.

HTTPS:

HyperText Transfer Protocol Secure. Most people think that the S stands for SSL. It is a method of transmitting data between a server and a browser.

SSL:

Secure Sockets Layer. A term coined by Netscape (later AOL). This is a proprietary term and there are legal issues regarding its use.

Many people use it regardless and so it is the commonly known 'name' of TLS– indeed, more people probably use the SSL to refer incorrectly to TLS than there are people who use the term TLS correctly!

Some people say SSL/TLS to refer to TLS but they say SSL/TLS because they know most people mistakenly think it is SSL.

TLS:

Transport Layer Security. A term coined to avoid legal issues with Netscape.

TLS 1.0 is often called 'SSL 3.1"

Encoding:

Transforming data using a scheme that, if someone else knows just the scheme they can decode it.

Encoding can be used for making data smaller, or just 'for convenience' or to make casual observation impractical.

For the technically minded: ASCII or EBCDIC are both encoding methods.

Some people use encoding with 'secret schemes' as a replacement for encryption. We don't and we don't recommend it given how easy it is these days to get a proper encryption working. See encrypting.

Decoding:

The opposite of Encoding, taking something that is encoded and turning it into its original form. Requires knowledge of the encoding scheme.

Encrypting:

Similar to Encoding but using something like a password so knowing the scheme to Encrypt is not enough – you need additional information to decrypt.

Encrypting is typically used to make data secret/hard to read

Decrypting:

The opposite of Encrypting, taking something that is encrypted and turning it into its original form. Requires knowledge of the Encryption scheme and encryption key(s). (Note: In some cases, the decryption key is different from the encryption key.)

Hashing:

For data integrity. Being able to quickly get a high degree of confidence that the data is 'correct' and 'uncorrupted'.

For data comparison. Being able to compare two large sets of data by seeing if their hash's are the same.

You can combine Encryption with Hashing depending on your use case.

Many systems will store your password as a hash. So where we can, for example, we would hash the password on the client, then send the hash to be compared. Why would we do that? Because a lot of people use the same password on many servers, so only being able to see the hash means you are unlikely to be able to use their password on another system.

Most 'hashes' do not contain enough information to regenerate the source and this means that many 'hashes' are one way. In these cases, even if you know how the hash is being created, you can't generate the source data.

A password is often an exception where the hash is longer than the password so, at least in theory, there could be enough data to generate the source.

Requirements and preferences:

• The same input must always produce the same output.
• For many hashes it is desirable that any 'small' modification in the input should result in a drastic change to the hash, but there is no technical requirement for that and it depends on the purpose of your hash whether this is important. Clearly if your purpose is the password use case above you would want this to be true.
• It should be very unlikely or impossible for 2 different source inputs to produce the same hash.
• It normally should be impossible to go from the output to derive the input.

Appendix: Interesting side notes on SHA1

On conversations dated April 15th, 2015 I read people saying basically that SHA1 was only theoretically breakable:

No actual break involving SHA-1 and using a structural weakness of SHA-1 has been currently fully demonstrated in academic conditions, let alone in the wild.

The best we have right now is a theoretical collision attack that should allow an attacker to compute a SHA-1 collision with effort "about 261", which is huge but still substantially less than the 280 resistance expected from a "perfect" hash function with 160-bit output. While 261 is within reach of existing technology, it is too expensive for even rich universities to casually indulge into that kind of experiment. So no actual collision has been produced yet. Moreover, for a practical attacker, computing a collision rarely grants a lot of power -- the attacker must usually compute a collisions with some degree of control on the contents of the colliding messages, which may be harder (or not).

http://security.stackexchange.com/questions/86609/this-is-2015-has-sha1-been-exploited-or-cracked-yet

In 2013 it was estimated to take 2.7 million dollars worth of computer time to crack a SHA-1, in Nov 15 it was down to 100K.