We need to make certs free and deprecate HTTP in favour of HTTPS with AES/TLS

darkphoenix22

Seems like the tech community at large is strongly in favour of depreciating HTTP for HTTPS with AES/TLS. Like how we depreciated telnet and rsh for SSH a while back.

Some useful utilities in light of Harper's new Internet Surveillance Law:

HTTPS Everywhere (Firefox): http://www.eff.org/https-everywhere

KB SSL Enforcer (Chrome): https://chrome.google.com/webstore/detail/flcpelgcagfhfoegekianiofphddckof

---

My Internet Privacy Platform: https://www.pirateparty.ca/forum/index.php?topic=898.0

---

We need to make certs free (provided by a crown corporation) and deprecate HTTP in favour of HTTPS with AES/TLS.

https://www.eff.org/pages/how-deploy-https-correctly

https://pay.reddit.com/r/canada/comments/hanjx/some_useful_utilities_in_light_of_harpers_new/

darkphoenix22

http://canadianawareness.org/2011/05/meet-the-new-bill-c-51/

The substance of the proposals that have the potential to fundamentally reshape the Internet in Canada. The bills contain a three-pronged approach focused on information disclosure, mandated surveillance technologies, and new police powers.

The first prong mandates the disclosure of Internet provider customer information without court oversight. Under current privacy laws, providers may voluntarily disclose customer information but are not required to do so. The new system would require the disclosure of customer name, address, phone number, email address, Internet protocol address, and a series of device identification numbers.

While some of that information may seem relatively harmless, the ability to link it with other data will often open the door to a detailed profile about an identifiable person. Given its potential sensitivity, the decision to require disclosure without any oversight should raise concerns within the Canadian privacy community.

The second prong requires Internet providers to dramatically re-work their networks to allow for real-time surveillance. The bill sets out detailed capability requirements that will eventually apply to all Canadian Internet providers. These include the power to intercept communications, to isolate the communications to a particular individual, and to engage in multiple simultaneous interceptions.

Moreover, the bill establishes a comprehensive regulatory structure for Internet providers that would mandate their assistance with testing their surveillance capabilities and disclosing the names of all employees who may be involved in interceptions (and who may then be subject to RCMP background checks).

The bill also establishes numerous reporting requirements including mandating that all Internet providers disclose their technical surveillance capabilities within six months of the law taking effect. Follow-up reports are also required when providers acquire new technical capabilities.

The requirements could have a significant impact on many smaller and independent Internet providers. Although the bill grants them a three-year implementation delay, the technical capabilities extend far beyond most of their commercial needs. Indeed, after years of concern over the privacy impact associated with deep-packet inspection of Internet traffic (costly technologies that examine Internet communications in real time), these bills appear to require all Internet providers to install such capabilities.

Having obtained customer information without court oversight and mandated Internet surveillance capabilities, the third prong creates a several new police powers designed to obtain access to the surveillance data. These include new transmission data warrants that would grant real-time access to all the information generated during the creation, transmission or reception of a communication including the type, direction, time, duration, origin, destination or termination of the communication.

Law enforcement could then obtain a preservation order to require providers to preserve subscriber information, including specific communication information, for 90 days. Finally, having obtained and preserved the data, production orders can be used to require the disclosure of specified communications or transmission data.

While Internet providers would actively work with law enforcement in collecting and disclosing the subscriber information, they could also be prohibited from disclosing the disclosures as court may bar them from informing subscribers that they have been subject to surveillance or information disclosures.

Few would argue that it is important to ensure that law enforcement has the necessary tools to address online crime issues. But these proposals come at an enormous financial and privacy cost, with as yet limited evidence that the current legal framework has impeded important police work. In fact, when then Public Safety Minister Peter Van Loan tried to justify his lawful access package, he pointed to an emergency situation that I later revealed (via access to information) had nothing to do with the Internet.

Now here is my 2 cents.

To all of us who have been paying attention to what is happening to our country, this should come as no surprise. This bill was actually introduced in November of 2010, but it did not move forward. Until now, when Harper has his majority and can push through whatever he wants. Another secret initiative with no substance behind the official explanation for it.

The reality is that the ruling class of this world are not happy about the internet and its freedoms. Alternative media has risen to all time highs and only continues to grow. Their control is being broken. Issues like the North American Security Perimeter, the NAU, and the total clearance sale of every fundamental piece of our sovereignty are being blown wide open!

In the elites eyes, this must be stopped. So why not make it a crime, and totally monitor the internet for political dissidents. Only makes sense right?

We have got one hell of a fight starting, on countless fronts! Are you ready for it? Or are you going to go quietly into the night?

https://secure.wikimedia.org/wikipedia/en/wiki/CAcert.org

CAcert.org is a community-driven certificate authority that issues free public key certificates to the public (unlike other certificate authorities which are commercial and sell certificates). CAcert has nearly 150,000 verified users and has issued over 548,000 certificates as of January 2010[update].

These certificates can be used to digitally sign and encrypt email, authenticate and authorize users connecting to websites and secure data transmission over the Internet. Any application that supports the Secure Socket Layer (SSL) can make use of certificates signed by CAcert, as can any application that uses X.509 certificates, e.g. for encryption or code signing and document signatures.

splash

In the wikipedia article for Firesheep: "Also, in Mozilla Firefox 4 (or later) as well as Google Chrome (version 4 and later) the user may natively hand-configure the browser to treat the site as HTTPS-only."

Maybe the issue is if you use https on your site make it all https? I'm interested in seeing more comments.

Also, on the issue of internet privacy, don't you think it should be a law that you are given easy access to shut down your account and have all your account information removed within a certain amount of days and your information is not allowed to be transfered or sold to another party during this period.

darkphoenix22

splash wrote: »

Also, on the issue of internet privacy, don't you think it should be a law that you are given easy access to shut down your account and have all your account information removed within a certain amount of days and your information is not allowed to be transfered or sold to another party during this period.

I agree with everything, especially the mandatory forum data rotation.

But one step at a time.

darkphoenix22

BTW there are separate SSL classes already, with differences in the way they are shown in the browser. Class 1 could just be reclassified as being encryption only and shown as such in the browser.

https://www.startssl.com/?app=40

stigweard

There is really only one thing in the amendments that sticks in my craw - "However, a TSP may still voluntarily preserve data and provide it to a law enforcement agency, even where there is no demand or order (new s. 487.0195 of the Code)." (Implementation details are going to be an issue as well - in the end it will likely mean a higher monthly bill for the consumer.)

The proposed amendments only allow for the collection transmission data, not content. Regarding the collection of information through preservation demand (without a court order), from what I have read, it can only be held for three months before being destroyed unless a warrant has been successfully obtained. They don't get to have a peek at what is in there beforehand.

The bigger issue relates to security tools that have legitimate uses which would become illegal to import or have in your possession. At the extreme, we would no longer be able to obtain or use password recovery tools, hacking tools for intrusion testing, or the like. In reality, it remains to be seen how it will play out.

For those interested, the full bill is available here. Compare it to the current criminal code to get a better idea of how it will look once it passes.


edit: I don't really want to be negative about this, but the idea of deprecating http is mostly a waste of time. In the end it is only going to dilute the current usefulness of https. If you look at the long version of c-52, isp are required to provide non encrypted endpoint content if the information collected turns out to be encrypted. I followed the reddit thread (I don't post there), and there seems to be a high number that haven't even read the proposed bills.

darkphoenix22

Why is anything on the Internet in cleartext anymore?

techophile at Ars Technica wrote:

Encrypting all net communication would be a net (heh) good. There's no excuse for transmitting over cleartext in this day and age -- when you can turn on HTTPS in Facebook and Twitter, when FireSheep and its ilk are not only possible but actual, it's clear that everything you do online is important -- it's a matter of degree only.

HTTPS is pretty fundamentally shit (because of the need for CAs, and the lack of any real oversight of CAs), but it's better than HTTP. Unfortunately there isn't really anyone who can push through unilateral type updates like that; if we get to encrypted-by-default it will be a slow, painful process.

It needs to be done though; I just don't know how. As a software dev I'll tell you I will never again write a site or service that does not support encrypted comms, though -- HTTPS for now, whatever the better alternative is tomorrow.

http://arstechnica.com/civis/viewtopic.php?p=21646755#p21646755

darkphoenix22

The trouble with SSL certificates is that you ultimately trust the CAs that issue them. Your plan to have a "crown corporation" issue SSL certs just indicates that you misunderstand how the technology works. You do NOT want the government to issue SSL certs, because the government can then simply go to that corporation and say "please issue us certificates for google.com, skype.com, reddit.com and a wildcart certificate for *.ca, thanks". Then they can man-in-the-middle your SSL connections to these sites and monitor your traffic without your browser giving as much as an "invalid certificate" error.

If you are concerned about RCMP sniffing your traffic, not only do you not want to have a "crown corporation" issuing globally trusted SSL certificates, you will want to purge all Canadian CAs from your trusted CA list. Though I'm not sure there's ground work for it in place yet, further developments may make it possible for RCMP to go to a Canadian CA, such as GlobalSign, for example, and demand that they issue them such "backdoor certificates" under a gag order.

As you can see, unfortunately, SSL is not a panacea because 1) there is no way to prevent some random CA from issuing trusted certs to any domain, as long as it's chained to a trusted root that's in your browser, 2) because there are now so many CAs that you should place very little trust in them, and 3) because 99% of the online public pays little to no attention to certificate errors anyway, always clicking "yes" in any error dialog.

TL;DR: HTTPS helps make us more secure from criminals, but it's not going to make us more secure from governments.

http://www.reddit.com/r/canada/comments/hanjx/some_useful_utilities_in_light_of_harpers_new/c1u4jdn


=====


Seems like SSL/TLS is rather unsuitable for universal encryption due to the centralization of the CAs and the problem of duplicate and fake certs.

Perhaps we could replace SSL/TLS with OpenPGP combined with DNSSEC. Out of curiosity, what would the drawbacks of replacing SSL/TLS with OpenPGP combined with DNSSEC be?

http://en.wikipedia.org/wiki/Transport_Layer_Security
http://en.wikipedia.org/wiki/Pretty_Good_Privacy
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

---

Note: We should still use utilities like HTTPS Everywhere as any encryption is better than no encryption. However, we need to look to the future and form a plan to replace TLS/SSL as it is not suitable for universal web encryption.

https://www.eff.org/https-everywhere

Phyphor

PGP uses the same technologies, only instead of a hierarchical authority system, you have a distributed web; the problem is that you connect to foo.com and it sends you a cert stating that yes, you really are talking to foo.com. Now, your client needs to determine if it should trust that cert.

Standard practice is to walk the chain of signatures up to the root and check if the root is in the trusted list
PGP checks if any trusted 3rd parties in your "web of trust" vouch for it

The problem with a website is that unless you happen to have someone who has vouched for that particular site in your web (or I suppose a chain of people who have), you can't actually verify the cert.

PGP puts the onus on the individual user to make sure the keys he accepts are actually valid. The fundamental problem in this scheme is that you cannot buy a new computer, turn it on, go to httpgp://your.bank.com and actually be able to trust the security at all, unless you include a list of people with "signing authority" and then you've just recreated the current situation.

darkphoenix22

Phyphor wrote: »

PGP uses the same technologies, only instead of a hierarchical authority system, you have a distributed web; the problem is that you connect to foo.com and it sends you a cert stating that yes, you really are talking to foo.com. Now, your client needs to determine if it should trust that cert.

Standard practice is to walk the chain of signatures up to the root and check if the root is in the trusted list
PGP checks if any trusted 3rd parties in your "web of trust" vouch for it

The problem with a website is that unless you happen to have someone who has vouched for that particular site in your web (or I suppose a chain of people who have), you can't actually verify the cert.

PGP puts the onus on the individual user to make sure the keys he accepts are actually valid. The fundamental problem in this scheme is that you cannot buy a new computer, turn it on, go to httpgp://your.bank.com and actually be able to trust the security at all, unless you include a list of people with "signing authority" and then you've just recreated the current situation.

I just think the identification and encryption parts of TLS/SSL need to be decoupled.

And there are keyservers for OpenPGP that can be used to verify the keys. I know because I had to use them when I was making packages for my Linux distro.

Phyphor

You can't separate them, the identification is based on being able to encrypt with a specified pair of keys

Those keyservers are simply the "CAs" for those distros, how is that any different?

Apothe0sis

Signing and encrypting are separate functions and can use different sub-certificates/keys already.

Phyphor

Well, signing uses the (possibly modified) encryption primitives. The simplest signature algorithm is just E(private, H(m)). It's separate from the data encryption, however the key exchange for that is done through the certificate public key.

The basic process (if I'm remembering correctly and ignoring algorithm negotiation) is

Server sends cert and cert_signature
Client checks that the CA is trusted the certificate matches what it expects and that H(cert) == E(capublic, cert_signature) (slightly more complicated for certs not signed by the root CA)
Client generates symmetric key K and sends M = E(certpublic, K)
Server gets K = E(certprivate, M)

Unknown

This content has been removed.

splash

Wow I wish I knew more technical speak on this issue.