81–90 of 136 posts
Lesser known HTTP feature that I love, instead of linking to resources like follows: http://static4.scirra.net/images/favicon.ico /> You should link as follows: The double forward slash will select the current protocol the page is being viewed on which means no security errors if you're switching between http/https!
I always expected this to do the same: If it doesn't, then what does it do? Default to http?
Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out the parts specific to our product, but the rest may be interesting. I would love feedback on things I may have missed. FWIW, it doesn't instill great confidence in SSL, but it isn't completely horrible. ------------------------ 1. It is possible to pretend to be…
1) You can address it in Chrome with pinning [1]. Built in pins require that you be a significant site, but you can also set them with HTTP headers [2]. [1] http://www.imperialviolet.org/2011/05/04/pinning.html [2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 This is a rather poor solution. The longer term one is Certificate Transparency: http://www.links.org/?p=1219 2) is solved with HSTS [3]. You can…
This would be fairly lightweight way for me to say which CA(s) I use for a particular domain.
One item that this (excellent) blog post does not adress is what to do about referer information which is generally not passed along when clicking on links on sites being browsed over SSL. In order to "get credit" for all of the traffic that they send everywhere twitter had to develop a fairly elaborate system of redirections (built into t.co) to make sure that clicks from twitter.com ended up being sent out to the r…
Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out the parts specific to our product, but the rest may be interesting. I would love feedback on things I may have missed. FWIW, it doesn't instill great confidence in SSL, but it isn't completely horrible. ------------------------ 1. It is possible to pretend to be…
1) You can address it in Chrome with pinning [1]. Built in pins require that you be a significant site, but you can also set them with HTTP headers [2]. [1] http://www.imperialviolet.org/2011/05/04/pinning.html [2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 This is a rather poor solution. The longer term one is Certificate Transparency: http://www.links.org/?p=1219 2) is solved with HSTS [3]. You can…
I don't understand that. If I serve http://example.com/mypage which has a link to http://mint.com/justin, you won't convert that to https://mint.com/justing, right? Even if example.com has HSTS enabled? Cause that would assume that mint.com has https, or else the whole thing breaks.
Cause in that case a man in the middle can just insert links to other domains (say, http://examp1e.com/myotherpage when I was serving a link to http://example.com/myotherpage) and still have the attack work. Like the GP said, only starting at an HTTPS page would solve this.
But you're the expert and I'm not, so what am I missing? :-)
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. This is too good to be true.
I assure you that it's true. I haven't reprofiled in that much detail since but I suspect that the numbers look even better now. Partly because computers are faster and partly because of software improvements.
1% of what? Sure, if you're doing a lot of database read/writes for every HTTP request, then yes, that makes sense. I guess it that case, the actual HTTP would account for (say) 0.1% of CPU load – which makes HTTPS 10 times slower.
I think we should compare HTTP and HTTPS connection creation/maintaining/dropping resource consumption relative to each other, not to the whole process that takes to process request, query databases, create page and send it to browser.
I'm no expert in this matter, so I could be (and probably am) completely wrong. That assertion sounded counter-intuitive to everything I've ever heard, and as it is expressed a little vague, I doubted it.
Earlier quoted context omitted.
1) You can address it in Chrome with pinning [1]. Built in pins require that you be a significant site, but you can also set them with HTTP headers [2]. [1] http://www.imperialviolet.org/2011/05/04/pinning.html [2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 This is a rather poor solution. The longer term one is Certificate Transparency: http://www.links.org/?p=1219 2) is solved with HSTS [3]. You can…
2) is solved with HSTS [3]. You can contact me (@chromium.org) to be built in. There isn't a notability requirement. I don't understand that. If I serve http://example.com/mypage which has a link to http://mint.com/justin , you won't convert that to https://mint.com/justing , right? Even if example.com has HSTS enabled? Cause that would assume that mint.com has https, or else the whole thing breaks. Cause in that cas…
EDIT: and well it doesn't seem that mint.com even has HSTS enabled... so bad example :P
Earlier quoted context omitted.
Apparently, yes. https://en.wikipedia.org/wiki/Generic_trademark#Trademark_er...
IANAL, but since the content in question is not a trademark, I do not think that genericization applies. Since Hyperbole and a Half is Creative Commons licensed (CC-NC-ND), it looks like its licensing requirements would be satisfied by attributing the original source ( "Proper credit includes a prominent, easily visible link to the source of the material you want to use..." )[1]. I think making sure that images in yo…
Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out the parts specific to our product, but the rest may be interesting. I would love feedback on things I may have missed. FWIW, it doesn't instill great confidence in SSL, but it isn't completely horrible. ------------------------ 1. It is possible to pretend to be…
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.
Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out the parts specific to our product, but the rest may be interesting. I would love feedback on things I may have missed. FWIW, it doesn't instill great confidence in SSL, but it isn't completely horrible. ------------------------ 1. It is possible to pretend to be…
[1] https://addons.mozilla.org/en-US/firefox/addon/perspectives/