Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should All Web Traffic Be Encrypted?

codinghorror.com

Post reply on HN
Print view View original

121–130 of 136 posts

Re: Should All Web Traffic Be Encrypted?

#121

Post by Zirro »

pavel_lishin wrote: post #119
rplnt wrote: post #107

Earlier quoted context omitted.

> If HTTP referrers never existed, the web would still be huge and would still be full of amazing content. While we're at it, let's get rid of User-Agent. No sarcasm intended, I'm serious. It only does bad things.

I disagree - it's nice to be able to serve a mobile layout to a mobile device. If I'm trying to load, say, CNN or ESPN on an older mobile phone, I don't need all the cruft that comes with the desktop version. (We can get into all the evils suggested by http://xkcd.com/869/ , but for the purposes of this argument I'm assuming that web developers and sysadmins are competent and not evil.)

What about media queries?

(https://developer.mozilla.org/En/CSS/Media_queries)

Re: Should All Web Traffic Be Encrypted?

#122

Post by dredmorbius »

marshray wrote: post #64
dredmorbius wrote: post #43

Earlier quoted context omitted.

They could if it were a reversible key-based hash. http://en.wikipedia.org/wiki/Cryptographic_hash_function

I believe you're thinking of a 'cipher'. Cryptographic hashes (even keyed ones) are expected to be one-way functions.

Could be my bad here, but I said "reversible key-based", which isn't what most cryptographic one-way hashes are.

For ASCII text, modulo 13 is a reversible operation (a/k/a rot13). It's not key-based, may not be a hash, and I'm not aware of any specifically key-based hashes, but that's along the lines of what I was thinking.

Fully admitting winging this one though.

Re: Should All Web Traffic Be Encrypted?

#123

Post by pavel_lishin »

Zirro wrote: post #121
pavel_lishin wrote: post #119

Earlier quoted context omitted.

I disagree - it's nice to be able to serve a mobile layout to a mobile device. If I'm trying to load, say, CNN or ESPN on an older mobile phone, I don't need all the cruft that comes with the desktop version. (We can get into all the evils suggested by http://xkcd.com/869/ , but for the purposes of this argument I'm assuming that web developers and sysadmins are competent and not evil.)

What about media queries? ( https://developer.mozilla.org/En/CSS/Media_queries )

Those don't really affect the HTML that gets sent.

    # wget --user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3" http://www.cnn.com/ -O cnn.mobile.html
    # wget http://www.cnn.com/ -O cnn.standard.html
    # ls -lhrt | grep cnn 
    -rw-r--r--    1 pavel  staff    29K Feb 24 13:12 cnn.mobile.html
    -rw-r--r--    1 pavel  staff   104K Feb 24 13:13 cnn.standard.html
I don't need 100K worth of stuff on BlackBerry 1.half's browser that can't render most of it.

Re: Should All Web Traffic Be Encrypted?

#124

Post by TomGullen »

gurkendoktor wrote: post #109
eurleif wrote: post #77

Earlier quoted context omitted.

That's a relative URL. It would be equivalent to http://static4.scirra.net/static4.scirra.net/images/favicon....

Wow, this took forever to click. I have never written sites that spanned several servers like that. Thanks!

It's all on one server! We use Scirra.net as a cookieless domain to serve static content from (images, css, js etc) as this speeds requests up because otherwise the cookie data for the page is sent to every resource on the same domain which can slow the page load down somewhat.

1 cookieless domain is probably fine, but I found out that for us 4 subdomains (static1, static2, static3, static4) gives best page load performance. It's been a while now so I've forgotten exactly the reason why more can be good, but I believe the benefit of multiple cookieless domains is to do with parallelisation of requests.

If you set it up right it's pretty easy to do, I just have a function that randomly generates the static URL based on the hash of the name of the resource it's linking to.

For example:

" />

The function then hashes the filename, randomly allocates it to static1,static2,static3 or static4 and then prints the path. Hashing is important, you don't want the resource skipping round static servers otherwise it wont be able to cache, and as hashes are designed to have a random distribution most pages static resources should be pretty evenly spread out across the 4 static sub-domains (I do tweak it on some pages though like the homepage as sometimes it comes out quite unbalanced).

All the staticN.scirra.net subdomains all point to the same folder.

Some people think it's overkill and a waste of time but it's not. Once it's setup right it's very low maintenance. Also, the pages load very fast :) I would offer you to see our homepage http://www.scirra.com but it's in a transitional stage of moving server so a lot of it is quite slow at the moment!

Page load speed is super important especially on the visitors first visit/request. Every second longer it takes the more visitors are going to press back or cancel the request. People are also capable of differentiating between very small periods of time (~10-30ms) so really every ms counts. A fast page load also sets a good precedent that your site is going to be one they will enjoy to browse as no waiting is involved.

Re: Should All Web Traffic Be Encrypted?

#125

Post by gwern »

JoshTriplett wrote: post #15
pnathan wrote: post #10

Earlier quoted context omitted.

> is definitely stored in plain text in the googlesphere have a source for that?

By definition, since Google can index email and mine it for keywords, they have access to the contents of it, which makes it isomorphic to plaintext.

They almost surely are for a myriad of reasons, but searchability does not imply a database must be isomorphic to plain text: searchable encrypted database techniques have long existed and have been implemented as things like CryptDB http://css.csail.mit.edu/cryptdb/ which let you set the level of encryption and how much information leakage is possible.

Re: Should All Web Traffic Be Encrypted?

#126

Post by aidenn0 »

icebraining wrote: post #89
aidenn0 wrote: post #57

Earlier quoted context omitted.

How have I never seen convergence? I've been bitching about the weaknesses in the CA system for years, and totally missed that someone has done something about it.

See also Perspectives[1], on which Convergence is based. [1]: http://perspectives-project.org/

Yeah, I'm aware of that, but it had some privacy issues that convergence seems to have figured out

Re: Should All Web Traffic Be Encrypted?

#127

Post by aidenn0 »

mike-cardwell wrote: post #101
slavak wrote: post #90

Earlier quoted context omitted.

How is Convergence different from the Perspectives add-on[1]? I ask because I honestly don't see any significant advantage to one over the other. [1] https://addons.mozilla.org/en-US/firefox/addon/perspectives/

Convergence has a proxy system built in so you connect to notaries via other notaries. It's a rather rudimentary attempt at offering privacy to the user looking up the certificate. It (rightly or wrongly) works on the assumption that people running notaries wont collude.

Perspectives always leaks information about which sites you are visiting to all notaries.

Convergence leaks information about which sites you are visiting for the first time with the current key only if your bounce notary colludes with one other notary.

Re: Should All Web Traffic Be Encrypted?

#128

Post by marshray »

dredmorbius wrote: post #122
marshray wrote: post #64

Earlier quoted context omitted.

I believe you're thinking of a 'cipher'. Cryptographic hashes (even keyed ones) are expected to be one-way functions.

Could be my bad here, but I said "reversible key-based", which isn't what most cryptographic one-way hashes are. For ASCII text, modulo 13 is a reversible operation (a/k/a rot13). It's not key-based, may not be a hash, and I'm not aware of any specifically key-based hashes, but that's along the lines of what I was thinking. Fully admitting winging this one though.

Well your Wikipedia link was about cryptographic hash functions so I figured that's what you intended to refer to.

So when you wrote "key-based hashes", I interpreted that as meaning a cryptographic hash-like function with key input, e.g. HMAC the "Keyed-Hash Message Authentication Code".

Modulo 13 is different than rot13. Modulo 13 is actually a hash function, whereas rot13 is a permutation.

If rot13 took a key (e.g. if it were rotN instead) it would make a primitive cipher. But it doesn't, so it behaves like a cipher that is always used with a fixed key or a cipher the key is already decided in the context of discussion.

The process of applying a specific key to a cipher is called "keying". So just to make things even more confusing, we could perhaps refer to rotN (AKA "rot13") then as a "keyed cipher".

:-)

Re: Should All Web Traffic Be Encrypted?

#130

Post by rogerbinns »

chc wrote: post #71
rogerbinns wrote: post #61

Earlier quoted context omitted.

Expanding on 1) you can also play man in the middle, decrypt and resign traffic with your own faked CA. If you ever have access to the users' machine you can install your faked CA as trusted and could have done it long in advance (eg via trojans/viruses). When I was working on WAN optimizers I actually did this during research. All the various sites I visited still proudly told me how they were "Verisign Trusted" and…

If you've already owned the box, why would you bother with MITM?

I was working on WAN optimisers - ie something that would be sold to customers. With WAN optimizers you would typically put one in a branch office and one at headquarters. The boxes would then compress traffic between them. Typical compression ratios are 20x/95% - in other words your WAN link can now transfer about 20 times as much traffic. Additionally some traffic would be modified to do read ahead and write behind to provide latency improvements. An example of that was a user in Malaysia opening a Word document in San Jose, CA that was a 75kb file. Without a WAN optimiser it would take almost 3 minutes while with one it would take 5 seconds.

The problem with SSL traffic is that it is encrypted and doesn't repeat even for identical underlying data, and hence can't be compressed, nor can it be modified. This significantly hurts performance. To work well the SSL would need to be stripped off, the traffic compressed/read ahead etc, sent over the WAN and then SSL put back on. (The communication between the WAN optimisers was itself within IPSec or SSL.) SSL is designed so that you can't pull shenanigans like this, unless you have the private key of the servers, or resign the traffic with a different CA that can generate the needed certificates on the fly and are "trusted" by the user.

Many internal corporate services have moved to SSL and branch office users need to access them. Think about benefits systems, HR, documents, accounting, sales forecasting and tracking etc.

Post reply on HN