How to implement HTTPS in an insufficient manner • Hacker News Board

Re: How to implement HTTPS in an insufficient manner

#61

Post by adamauckland » Thu, Apr 04, 2013, 8:48 PM UTC

claudius wrote: post #22

webignition wrote: post #17

Earlier quoted context omitted.

Firstly, an attacker with access to your backend database will have full access to user credentials if passwords are not salted and hashed. An attacker can then sign in as any user. The attacker may not be trying to steal all your have and may instead be looking to make life difficult for a single specific user. Secondly, users will reuse passwords. An attacker with access to the plaintext password and the user's ema…

I give you the first three points, though at least the first one sounds a little academic, given that someone with access to the backend database could probably effect queries ‘simulating’ an active user. However, > Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen. sounds odd, since t…

I'm guessing you're trolling, but I'll bite...

" given that someone with access to the backend database could probably effect queries ‘simulating’ an active user."

Yes, in shortsightedland. In a company where storing plaintext passwords is normal, it's not too far fetched to think that they are probably backing up and restoring their databases all over the shop.

They only need to lose a laptop on public transport and now they've basically distributed ALL their users common passwords.

Re: How to implement HTTPS in an insufficient manner

#62

Post by trust-me » Thu, Apr 04, 2013, 9:02 PM UTC

ivanr wrote: post #57

trust-me wrote: post #42

Earlier quoted context omitted.

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-t…

Yes, these are real problems, but how is redirecting to the home page helping in any way? When the user navigates back to the page she wanted the in-secure script will still be fetched. A MITM is still able to serve a copy of your page.

Re: How to implement HTTPS in an insufficient manner

#63

Post by GauntletWizard » Thu, Apr 04, 2013, 10:36 PM UTC

ivanr wrote: post #57

trust-me wrote: post #42

Earlier quoted context omitted.

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-t…

How about this: You run two instances of Apache, one only loaded with the rewrite rule and only serving on :80, and check those logs regularly?

Re: How to implement HTTPS in an insufficient manner

#64

Post by nwh » Fri, Apr 05, 2013, 2:23 AM UTC

devcpp wrote: post #60

nwh wrote: post #7

Earlier quoted context omitted.

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.

Their tools truncated my changed password to 25 characters silently (first clue), their password reset tool emailed the plaintext password back to me (second clue), and their "api" endpoint errors out when I use special characters in my password (last clue).

Re: How to implement HTTPS in an insufficient manner

#65

Post by ivanr » Fri, Apr 05, 2013, 6:40 AM UTC

GauntletWizard wrote: post #63

ivanr wrote: post #57

Earlier quoted context omitted.

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-t…

How about this: You run two instances of Apache, one only loaded with the rewrite rule and only serving on :80, and check those logs regularly?

You can check the logs even with a single web server instance, provided you keep separate access logs for ports 80 and 443. But people don't do that. Forcing the web site to break is also forcing the developers to realize there is a problem, and to deal with it.

Re: How to implement HTTPS in an insufficient manner

#66

Post by ivanr » Fri, Apr 05, 2013, 6:48 AM UTC

trust-me wrote: post #62

ivanr wrote: post #57

Earlier quoted context omitted.

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-t…

Yes, these are real problems, but how is redirecting to the home page helping in any way? When the user navigates back to the page she wanted the in-secure script will still be fetched. A MITM is still able to serve a copy of your page.

I wasn't arguing for redirecting to the home page, only to avoid redirecting (to the intended destination on port 443) automatically.

If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there). On your end you may even never see a plaintext request. But in all other instances, displaying an intermediary page is a chance to educate your users, and possibly get them to change their bookmarks.

Further, with little work you may be forcing the MITM to do some custom coding (a lot of work) in order to make the attack seamless.

I wouldn't do this for just any web site, but if you're running a bank or something similarly sensitive, it would probably be worth it.

Re: How to implement HTTPS in an insufficient manner

#67

Post by kijin » Fri, Apr 05, 2013, 7:48 AM UTC

ivanr wrote: post #66

trust-me wrote: post #62

Earlier quoted context omitted.

Yes, these are real problems, but how is redirecting to the home page helping in any way? When the user navigates back to the page she wanted the in-secure script will still be fetched. A MITM is still able to serve a copy of your page.

I wasn't arguing for redirecting to the home page, only to avoid redirecting (to the intended destination on port 443) automatically. If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there). On your end you may even never see a plaintext request. But in all other instances, displaying an intermediary page is a chance to educate your users, and possibly get them to change the…

If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there).

Not really. Although old browsers don't support HSTS, they still respect the "secure" flag in cookies. So if an old browser ever requests an insecure resource, no cookies are sent with it, so the bad guys can MITM your connection all day long and no harm will be done. You only need to make sure that your own web pages never request resources over HTTP, and this is relatively easy to do.

> On your end you may even never see a plaintext request.

If so, there's no point doing fancy redirects anyway. How do you redirect a request that you never see? Therefore this scenario isn't really worth losing sleep over.

> displaying an intermediary page is a chance to educate your users, and possibly get them to change their bookmarks.

Users don't want to be educated, period.

Also, technically when a browser encounters a 301 redirect, it should update the relevant bookmark automatically. In reality no browser does this, but that's what the standards say anyway.

Re: How to implement HTTPS in an insufficient manner

#68

Post by ivanr » Fri, Apr 05, 2013, 9:21 AM UTC

kijin wrote: post #67

ivanr wrote: post #66

Earlier quoted context omitted.

I wasn't arguing for redirecting to the home page, only to avoid redirecting (to the intended destination on port 443) automatically. If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there). On your end you may even never see a plaintext request. But in all other instances, displaying an intermediary page is a chance to educate your users, and possibly get them to change the…

If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there). Not really. Although old browsers don't support HSTS, they still respect the "secure" flag in cookies. So if an old browser ever requests an insecure resource, no cookies are sent with it, so the bad guys can MITM your connection all day long and no harm will be done. You only need to make sure that your own web pages…

> Although old browsers don't support HSTS, they still respect the "secure" flag in cookies. So if an old browser ever requests an insecure resource, no cookies are sent with it, so the bad guys can MITM your connection all day long and no harm will be done.

Not true. Once a MITM hijacks the victim's communication with the server, she can do whatever she wants, including stripping the "secure" flag from session cookies. She may not be able to compromise a previous secure cookie, but she can hijack a brand new session, wait for the user to authenticate, and gain access that way. The communication from the victim to the MITM will be plain-text with insecure session cookies; the communication from the MITM to the server can be SSL with secure cookies.

And if we're talking just about an insecure resource (not a page, but, for example, a JavaScript file), the MITM can simply inject malicious code into it and hijack the browser that way.