Earlier quoted context omitted.
If every blog on the internet had a static IP to serve HTTPS over, we'd have even less IP addresses available than we do now.
IPv6 or SNI
SNI has the added merit of working on practically everything these days.
How to implement HTTPS in an insufficient manner
51–60 of 68 posts
Re: How to implement HTTPS in an insufficient manner
#52Earlier quoted context omitted.
> If there was something worth protecting on a personal blog site, it might be a different story. It's not about security here, it's about privacy. https://willnorris.com/2012/12/all-https-all-the-time > This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.
HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
>> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.
Re: How to implement HTTPS in an insufficient manner
#53Https article served over http. Lovely. Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect…
If every blog on the internet had a static IP to serve HTTPS over, we'd have even less IP addresses available than we do now.
this went from good motivation for ipv6 switchover to obsolete excuse: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Re: How to implement HTTPS in an insufficient manner
#54Earlier quoted context omitted.
HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
>> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested. Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.
Yeah, essentially it comes down to timings/measuring payload lengths. Even for complex websites it may still be possible to attempt to infer what you're viewing. For example, if you are interested, take a look at this research paper which explains how to capture what a user is typing in an auto complete (i.e sends a request every time you type a character) box even over an encrypted connection:
http://research.microsoft.com/pubs/119060/WebAppSideChannel-...
Which could leak information about what you're looking at or looking for. The site is not mentioned specifically in the paper but Amazon uses a autocomplete for it's search which exhibits similar behaviour to what is discussed in the paper. So even on a site like Amazon if you visited it over a secure connection an attacker could most likely find out what you are searching for or looking at on Amazon.
Re: How to implement HTTPS in an insufficient manner
#55SSL should really be all or nothing. The same way browsers don't like loading insecure content from a secure origin, they should also squirm at the idea of submitting a form to a secure area (from non-secure) -- including if the parent is non-secure. An iframe isn't good enough.
Re: How to implement HTTPS in an insufficient manner
#56Earlier quoted context omitted.
>> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested. Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.
Yeah, essentially it comes down to timings/measuring payload lengths. Even for complex websites it may still be possible to attempt to infer what you're viewing. For example, if you are interested, take a look at this research paper which explains how to capture what a user is typing in an auto complete (i.e sends a request every time you type a character) box even over an encrypted connection: http://research.micros…
Thanks for the explanation and the link, much appreciated!
Re: How to implement HTTPS in an insufficient manner
#57Earlier quoted context omitted.
No, please don't do this: If a visitor goes to http://domain/some/url they should not redirect to https://domain/some/url - it makes it harder to catch pages that use the wrong protocol. Better to redirect http://domain/some/url to https://domain Edit: if you're logging referrers from your own domain with non https:// urls AND using secure cookies, ignore my comment!
Nooo, don't erase the address that took me 5 minutes to type. What you say doesn't make any sense. You should obviously configure the https redirect as a site wide setting and not per page.
That's clearly true from the usability perspective. However, the problem is that bulk redirections like that make it very difficult to catch insecure resources.
For example, let's suppose you have a secure page that's referencing some JavaScript resource via a plain-text connection. Because of the redirection, the browser will ultimately fetch the required file, but only trying plain-text HTTP first. That one plain-text request can be hijacked by a man-in-the-middle attacker and abused to take over the victim's browser (and account).
Further, if your users have bookmarks to plain-text pages, their first access to your web site is always going to be insecure, which means that they can be attacked via sslstrip.
These problems are solved with Strict Transport Security, but it will probably take some time until we can fully rely on it.
In the meantime, the plain-text URL can be preserved, and the redirection carried out via an intermediary page that explains why links to plain-text pages are dangerous. It's ugly, but I don't think there's a better (safer) way.
Re: How to implement HTTPS in an insufficient manner
#58Earlier quoted context omitted.
> all of them have to do with the fact that the website in question is not 100% HTTPS Problem number 4 is actually also relevant for HTTPS-only websites. That is, if the website doesn't use HSTS, and most don't. Also a 301 only works for one page . Consider this: You go to example.com (typed in address bar), it redirects you to https://example.com via a 301, then you load your favorite news website, I inject an ifram…
> Problem number 4 is actually also relevant for HTTPS-only websites. You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site. > Also a 301 only works for one page. You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they…
By the way, you will probably want to apply [B] to that rewrite rule. In order for mod_rewrite to do its thing, it has to URL-decode the path, which means that you will get decoded data in the $1 capture. In some cases, the resulting URL (after mod_rewrite) may end up being corrupted -- for example if there's a URL-encoded slash or question mark. The [B] flag tells mod_rewrite to URL-encode backreferences. The process is not guaranteed to end up with the same URL, but with [B] it is at least a bit safer.
Re: How to implement HTTPS in an insufficient manner
#59This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…
Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with…
Probably the same reason civil engineers design every individual component several times stronger than they need to be. Redundant safety points mean multiple things have to simultaneously fail instead of just one thing.
Re: How to implement HTTPS in an insufficient manner
#60This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…
I emailed my ISP today to ask them why my password was being stored in plain text (and not even escaped) in a MySQL database. Their response was that everything was "working", so I didn't have to worry. Bear in mind, this is a company with my banking details. I have absolutely no expectation that it is going to be fixed either.
How do you know they do?
That said, you should have seen my face when my ISP emailed me my very password for online access, in plain text. It was something like 123456. Unforgivable double offense.