Slashdot Mirror

If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see.

- that's not the point, the point is that without encryption all of the communications are plain text and since they are all recorded they can be looked at later date.

Since today CAs are a BARRIER TO ENTRY for many of the people to bother to switch to encrypted communications, this prevents a large number of communications from being encrypted.

It is even worse if a CA is used to generate the key pairs, then it's not only the MITM attack that is problematic, then gov't can use that to decrypt your stored communications. So AFAIC CAs are a problem in a number of ways: they prevent too many people from encrypting the traffic and they can cooperate with the government, they are a chocking point.

untrusted self-signed cert is no better than using a CA-signed cert.

- for the cases when gov't did not implement MITM attack and wants to look at your PAST communications I completely disagree.

A self-signed certificate without MITM attack prevents gov't from looking at your past. CA that generates your keys is the biggest breach of security there is and browsers acting as if self-signed certificates are a virus coupled with CAs is a huge barrier to entry for a large number of people that prevents them from implementing self signed certificates.

2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.

- NONSENSE.

Nonsense, complete and utter nonsense.

I didn't address that scenario in my previous comment, it doesn't mean that it is how I would address it (not give a warning when a CA authorised certificate is replaced with a self signed certificate)!

You are reaching for too many straws, I feel you do have a dog in this fight. If the https://bank.com/ site with a CA authorised certificate switches from CA authorised certificate to a self signed one I don't have a problem with a big warning, in fact there should ALWAYS be a warning when a CA authorised certificate is replaced!

AFAIC ALL CA AUTHORISED CERTIFICATES ARE MITM ATTACKS. But I do not care about MITM attacks for the purposes of pushing more people to encrypted traffic, I only care that browsers do not treat self-signed certificates as if they are worse than PLAIN TEXT communications, which they are not! They are only a problem for CA's bottom line and for NSA spying.

An https://bank.com/ switching from one CA authorised certificate to another IS a MITM attack for all I know.

An https://bank.com/ switching from CA authorised certificate to a self-signed one is ALSO a MITM attack.

An https://bank.com/ switching to http://bank.com/ is ALSO a MITM attack.

If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see.

- that's not the point, the point is that without encryption all of the communications are plain text and since they are all recorded they can be looked at later date.

Since today CAs are a BARRIER TO ENTRY for many of the people to bother to switch to encrypted communications, this prevents a large number of communications from being encrypted.

It is even worse if a CA is used to generate the key pairs, then it's not only the MITM attack that is problematic, then gov't can use that to decrypt your stored communications. So AFAIC CAs are a problem in a number of ways: they prevent too many people from encrypting the traffic and they can cooperate with the government, they are a chocking point.

untrusted self-signed cert is no better than using a CA-signed cert.

- for the cases when gov't did not implement MITM attack and wants to look at your PAST communications I completely disagree.

A self-signed certificate without MITM attack prevents gov't from looking at your past. CA that generates your keys is the biggest breach of security there is and browsers acting as if self-signed certificates are a virus coupled with CAs is a huge barrier to entry for a large number of people that prevents them from implementing self signed certificates.

2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.

- NONSENSE.

Nonsense, complete and utter nonsense.

I didn't address that scenario in my previous comment, it doesn't mean that it is how I would address it (not give a warning when a CA authorised certificate is replaced with a self signed certificate)!

You are reaching for too many straws, I feel you do have a dog in this fight. If the https://bank.com/ site with a CA authorised certificate switches from CA authorised certificate to a self signed one I don't have a problem with a big warning, in fact there should ALWAYS be a warning when a CA authorised certificate is replaced!

AFAIC ALL CA AUTHORISED CERTIFICATES ARE MITM ATTACKS. But I do not care about MITM attacks for the purposes of pushing more people to encrypted traffic, I only care that browsers do not treat self-signed certificates as if they are worse than PLAIN TEXT communications, which they are not! They are only a problem for CA's bottom line and for NSA spying.

An https://bank.com/ switching from one CA authorised certificate to another IS a MITM attack for all I know.

An https://bank.com/ switching from CA authorised certificate to a self-signed one is ALSO a MITM attack.

An https://bank.com/ switching to http://bank.com/ is ALSO a MITM attack.

If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see.

- that's not the point, the point is that without encryption all of the communications are plain text and since they are all recorded they can be looked at later date.

Since today CAs are a BARRIER TO ENTRY for many of the people to bother to switch to encrypted communications, this prevents a large number of communications from being encrypted.

It is even worse if a CA is used to generate the key pairs, then it's not only the MITM attack that is problematic, then gov't can use that to decrypt your stored communications. So AFAIC CAs are a problem in a number of ways: they prevent too many people from encrypting the traffic and they can cooperate with the government, they are a chocking point.

untrusted self-signed cert is no better than using a CA-signed cert.

- for the cases when gov't did not implement MITM attack and wants to look at your PAST communications I completely disagree.

A self-signed certificate without MITM attack prevents gov't from looking at your past. CA that generates your keys is the biggest breach of security there is and browsers acting as if self-signed certificates are a virus coupled with CAs is a huge barrier to entry for a large number of people that prevents them from implementing self signed certificates.

2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.

- NONSENSE.

Nonsense, complete and utter nonsense.

I didn't address that scenario in my previous comment, it doesn't mean that it is how I would address it (not give a warning when a CA authorised certificate is replaced with a self signed certificate)!

You are reaching for too many straws, I feel you do have a dog in this fight. If the https://bank.com/ site with a CA authorised certificate switches from CA authorised certificate to a self signed one I don't have a problem with a big warning, in fact there should ALWAYS be a warning when a CA authorised certificate is replaced!

AFAIC ALL CA AUTHORISED CERTIFICATES ARE MITM ATTACKS. But I do not care about MITM attacks for the purposes of pushing more people to encrypted traffic, I only care that browsers do not treat self-signed certificates as if they are worse than PLAIN TEXT communications, which they are not! They are only a problem for CA's bottom line and for NSA spying.

An https://bank.com/ switching from one CA authorised certificate to another IS a MITM attack for all I know.

An https://bank.com/ switching from CA authorised certificate to a self-signed one is ALSO a MITM attack.

An https://bank.com/ switching to http://bank.com/ is ALSO a MITM attack.

If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see.

- that's not the point, the point is that without encryption all of the communications are plain text and since they are all recorded they can be looked at later date.

Since today CAs are a BARRIER TO ENTRY for many of the people to bother to switch to encrypted communications, this prevents a large number of communications from being encrypted.

It is even worse if a CA is used to generate the key pairs, then it's not only the MITM attack that is problematic, then gov't can use that to decrypt your stored communications. So AFAIC CAs are a problem in a number of ways: they prevent too many people from encrypting the traffic and they can cooperate with the government, they are a chocking point.

untrusted self-signed cert is no better than using a CA-signed cert.

- for the cases when gov't did not implement MITM attack and wants to look at your PAST communications I completely disagree.

A self-signed certificate without MITM attack prevents gov't from looking at your past. CA that generates your keys is the biggest breach of security there is and browsers acting as if self-signed certificates are a virus coupled with CAs is a huge barrier to entry for a large number of people that prevents them from implementing self signed certificates.

2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.

- NONSENSE.

Nonsense, complete and utter nonsense.

I didn't address that scenario in my previous comment, it doesn't mean that it is how I would address it (not give a warning when a CA authorised certificate is replaced with a self signed certificate)!

You are reaching for too many straws, I feel you do have a dog in this fight. If the https://bank.com/ site with a CA authorised certificate switches from CA authorised certificate to a self signed one I don't have a problem with a big warning, in fact there should ALWAYS be a warning when a CA authorised certificate is replaced!

AFAIC ALL CA AUTHORISED CERTIFICATES ARE MITM ATTACKS. But I do not care about MITM attacks for the purposes of pushing more people to encrypted traffic, I only care that browsers do not treat self-signed certificates as if they are worse than PLAIN TEXT communications, which they are not! They are only a problem for CA's bottom line and for NSA spying.

An https://bank.com/ switching from one CA authorised certificate to another IS a MITM attack for all I know.

An https://bank.com/ switching from CA authorised certificate to a self-signed one is ALSO a MITM attack.

An https://bank.com/ switching to http://bank.com/ is ALSO a MITM attack.

If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see.

- that's not the point, the point is that without encryption all of the communications are plain text and since they are all recorded they can be looked at later date.

Since today CAs are a BARRIER TO ENTRY for many of the people to bother to switch to encrypted communications, this prevents a large number of communications from being encrypted.

It is even worse if a CA is used to generate the key pairs, then it's not only the MITM attack that is problematic, then gov't can use that to decrypt your stored communications. So AFAIC CAs are a problem in a number of ways: they prevent too many people from encrypting the traffic and they can cooperate with the government, they are a chocking point.

untrusted self-signed cert is no better than using a CA-signed cert.

- for the cases when gov't did not implement MITM attack and wants to look at your PAST communications I completely disagree.

A self-signed certificate without MITM attack prevents gov't from looking at your past. CA that generates your keys is the biggest breach of security there is and browsers acting as if self-signed certificates are a virus coupled with CAs is a huge barrier to entry for a large number of people that prevents them from implementing self signed certificates.

2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.

- NONSENSE.

Nonsense, complete and utter nonsense.

I didn't address that scenario in my previous comment, it doesn't mean that it is how I would address it (not give a warning when a CA authorised certificate is replaced with a self signed certificate)!

You are reaching for too many straws, I feel you do have a dog in this fight. If the https://bank.com/ site with a CA authorised certificate switches from CA authorised certificate to a self signed one I don't have a problem with a big warning, in fact there should ALWAYS be a warning when a CA authorised certificate is replaced!

AFAIC ALL CA AUTHORISED CERTIFICATES ARE MITM ATTACKS. But I do not care about MITM attacks for the purposes of pushing more people to encrypted traffic, I only care that browsers do not treat self-signed certificates as if they are worse than PLAIN TEXT communications, which they are not! They are only a problem for CA's bottom line and for NSA spying.

An https://bank.com/ switching from one CA authorised certificate to another IS a MITM attack for all I know.

An https://bank.com/ switching from CA authorised certificate to a self-signed one is ALSO a MITM attack.

An https://bank.com/ switching to http://bank.com/ is ALSO a MITM attack.

... given the fact that governments are recording everything for assessment and for looking at it when time comes later. When time comes later, the information may still be recovered if the government is really really interested in finding out what it was that you wrote there, however it's going to be much more difficult than if it was plain text, there is nothing to recover with plain text, it's out in the open.

There are two scenarios here: either the government performs mitm attacks or they don't.

If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see. The govt can perform a mitm on the self-signed connectino by using their own self-signed cert, and the govt can perform a mitm on the CA-signed connection by forcing the CA to give up the CA cert and signing a new cert with the CA cert.

If they don't perform mitm attacks, the govt needs the website's cert to view the traffic. This means they either need foo.com's self-signed cert or bar.com's CA-signed cert. Either way, the CA's cert alone isn't good enough.

If you don't agree with those two scenarios, please explain which details are technically correct. (I'm fairly certain that none are.)

If you do agree, then it follows that you agree that using an untrusted self-signed cert is no better than using a CA-signed cert. The secure thing to do would be to use a trusted self-signed cert; that is, a self-signed cert whose fingerprint has been verified through a secure channel.

Saying that self signed certificates are worse than plain text is either propaganda for some ulterior motive or it is an irrational position, because the end user does NOT even have to be AWARE that a self signed certificate is used! In fact if the browser doesn't even tell the user that there is a self signed certificate, then to the user it looks like a plain text connection and maybe that's how browsers really should treat self signed certificates that are not manually authorised by the user.

That browser user interface change would create a huge security hole. Consider the following scenario:
1. Alice, the user, accesses https://bank.com/ which uses a CA-signed certificate.
2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.

It is COMPLETELY UNREASONABLE to expect Alice to notice that the HTTPS icon is missing. Many user studies have shown that users continue after seeing self-signed certificate warnings, which are impossible to miss and explicitly state the dangers of continuing.

But no one checks the certificate (well few people anyway), unless the browser flags them to.

What a lot of employers are doing is redirecting all https traffic to an internal proxy which uses the domain's (active directory domain that is) trusted certificate - so all domain clients automatically trust the certificate. So when you go to https://my.bank.com/ or whatever, you're actually going to your internal proxy, which is decrypting the traffic, inspecting it and then re-encrypting it with my.bank's certificate and sending it on.

You'd never know unless you clicked on the certificate in your browser and read the details. As the browser will leave the certificate "green" or whatever (trusted), 99.999999% of people would never think to check.

Microsoft's ISA has been offering this functionality since 2003 and in the latest versions, it's downright trivial to set this functionality up (I have done it for clients).

I always thought it was a bit evil and highly questionable to do this when staff are not aware, as it means the IT team can easily steal banking details, etc. It also puts a larger onus on the company to ensure their servers are not pwn3d by someone else. I get that it's all "company time and company equipment" - but when staff are not aware this is happening and exposing person information and banking details, etc, I think it's wrong.

There are several choices:

1) child porn
2) img links loading resources from non-onion sites (seems like this could be a number of different resources though, javascript etc) (also using a tinyrurl link to get to an onion site lets everyone know you're going there)
3) img links to malformed image files exploiting browser bugs (it's a forum called "hackbb" what do you expect?)
4) img links to https://bank.com/transfer-money.php?amount=5000&account=12345&verified=1 (see 3)

That's just off the top of my head. But I think paranoia about #1 is probably right.

How does it decrypt the traffic? It can't; only the parties in the SSL handshaking can do that, and that is the user's browser and the end server with its certificate.

Other posts on this thread detail how this is possible: You work for company X and go to https://bank.com./ Company X creates a Certificate Authority SSL certificate and installs it on all browsers. When you go to https://bank.com/ the proxy intercepts and pretends to be bank.com by generating a new server certificate for bank.com and talking to your browser as if it were bank.com. Since your browser trusts Company X's CA cert, it also trusts the fake cert created by the CA cert.

This is only possible if you are forced to use a browser with that CA cert installed, and the company has a proxy or other software/hardware that can essentially do a Man In The Middle attack.

How does it decrypt the traffic? It can't; only the parties in the SSL handshaking can do that, and that is the user's browser and the end server with its certificate.

Other posts on this thread detail how this is possible: You work for company X and go to https://bank.com./ Company X creates a Certificate Authority SSL certificate and installs it on all browsers. When you go to https://bank.com/ the proxy intercepts and pretends to be bank.com by generating a new server certificate for bank.com and talking to your browser as if it were bank.com. Since your browser trusts Company X's CA cert, it also trusts the fake cert created by the CA cert.

This is only possible if you are forced to use a browser with that CA cert installed, and the company has a proxy or other software/hardware that can essentially do a Man In The Middle attack.

I think the key difference is that you have to present a clear physical presence to break into tangible things like cars and houses. The perceived risk is higher, and you know people are going to be serious about locking you up. Breaking into wireless networks can be done by cowards, which increases the number of potential "attackers" greatly, whether or not the stakes are very high. Granted, your traffic *should* be secured by other means, but if you didn't properly secure your AP, you might not really notice if your bank page comes up http://bank.com/ instead of redirecting to https://bank.com/ like it usually does.

You've got a legitimate point; this is not exactly a shocking breakthrough, but I just wanted to play devil's advocate.

I think the key difference is that you have to present a clear physical presence to break into tangible things like cars and houses. The perceived risk is higher, and you know people are going to be serious about locking you up. Breaking into wireless networks can be done by cowards, which increases the number of potential "attackers" greatly, whether or not the stakes are very high. Granted, your traffic *should* be secured by other means, but if you didn't properly secure your AP, you might not really notice if your bank page comes up http://bank.com/ instead of redirecting to https://bank.com/ like it usually does.

You've got a legitimate point; this is not exactly a shocking breakthrough, but I just wanted to play devil's advocate.

1. As I've said, the CA doesn't own www.bank.com's private key - the CA only has its own private key.
2. The guy with the router still has to generate a different private key for generating the crack certificate - knowing the CA's private key doesn't help here.
3. And thus, the crack certificate will end up with e different fingerprint.

Add in the fact that you have plenty of people in China who have found ways to bypass the GFW, and that browsers seeing different fingerprints from the same website's certificates would give out red warning screens, your scheme is already not working well.

Next, it's about the CAs themselves. Every major OS and browser comes with a list of trusted CAs. Do you see many Chinese names there? No? And seeing Green Dam's PR disaster - if the Chinese government bothers to "coerce" foreign CAs to give them private keys, you can guess what the response is.

So, the reality is, even the Chinese government has no way of pulling out the already imperfect man-in-the-middle I described above. Yes, they can still give you a website with a different CA and probably with a self-signed cert, but again any sensible browser would jump up and down about it, which is definitely a strong motivator for anyone interested in privacy to somehow get foreign VPN access or simply just go to a Tor-like network.

Next common question... the textbook version of DH can be man-in-the-middled. While it is theoretically possible to MITM basic non-authenticated Diffie-Hellman without touching all the cert related stuff, it's not really practical since anonymous Diffie-Hellman is disabled by most web servers (e.g. the !ADH SSL cipher suite option in default Apache config) and I think most modern browsers wouldn't allow it anyway. What most real web servers do during SSL key exchange these days is either fixed DH or ephemeral DH, which aren't known to be susceptible to MITM unless the authentication in question isn't meaningful (e.g. self-signed certs, again, which is guaranteed to give you browser warnings)

As has already been discussed, though this is damn difficult under normal circumstances it's relatively trivial if you happen to be in control of the end-users PC through malware.

The premise with SSL is that once the host you're connecting to is verified, you trust the hosts on each end of the connection aren't compromised in some way. If this trust is misplaced, all security assumptions are straight out the window.

Example: You could do a fairly crude but effective hack just by fiddling with your victim's hosts file and injecting your own CA certificate into their certificate store.

That would give you a browser window which appears legit - it looks like it's connected to https://secure.bank.com/ there are no warning signs saying "Alert! This may not be bank.com!" and if the bogus CA cert claimed to be from Verisign I daresay that most people would never know the difference.

I suppose browser history would work, too. The attack described here actually uses a login test. The attacker's website includes a piece of JavaScript that routinely tries to access a page (or other Web-accessible item) that requires you to be logged in to the particular banking site to access. (Say, for example https://my.bank.com/account_summary.html.) It tests for failure/success and, if successful, pops up a dialog.

Beyond the fact that user should be able to tell, visually, what page the dialog is associated with, random-attacker's page shouldn't be able to access content on your bank as if you were logged in. It should have no way of knowing what the rest of your browser is doing. Noticing the bank in your history would be one way of seeing that you are or recently were logged in. In this case, the login test described works because session cookies, used to track a login session, are global in the browser. While the attacker can't easily access the cookie itself, it can (as described) test to see if it exists and is valid. With an ideal design, random-attacker's page would not only not have access to the cookie, but not have access to the *side effects* of having the cookie.

What if the cookie of the target site is against a host name such as

http://094ec182f4a74bc1382206407.bank.com/

The attacker would not waste their time trying to guess the (randomly generated) 094ec182f4a74bc1382206407 part.

So when you login your logging in with a host name with a token.

Stephan

Who cares if the connection which was used fetch the from the server was encrypted or not, the interesting part is what happens with the data that I entered to that form and then submitted over connection that I thought would be secure.

Who cares where the form came from?!?! Are you serious? Hmm. Well, there's the problem. If the casual user has decided to enter secret information into forms of unknown origin, then it doesn't really matter if the form's recipient uses a trusted key, since he doesn't know who the recipient is (until it's too late).

I'm at http://www.bank.com/ (note the lack of https) that I think is probably run by Bank Inc but I don't know for sure, since someone might be MitMing me, and I've been given no cert to check. My browser isn't displaying any trust info (such as a padlock icon) yet. Why would I enter any secrets onto that form? For all I know, that form is going to be sent (encrypted or unencrypted, I don't care) to www.thief.ru or some Javascript is capturing the info and sending it to http://www.bank.com/ even as I type stuff into it. I've been potentially compromised even before I click the submit button.

If I loaded the form from https://www.bank.com/ then at that point, the browser has already communicated to me how well I can trust (or not trust) that the page came from Bank Inc. That is the point where I can make a decision about whether or not to enter secrets into the form, or submit the form.

If you enter important secrets (ones where you really need authentication) into forms before you see padlock icons, then you've already lost. The browser's policies for dealing with certs, don't really matter, because no policy can save you.

Who cares if the connection which was used fetch the from the server was encrypted or not, the interesting part is what happens with the data that I entered to that form and then submitted over connection that I thought would be secure.

Who cares where the form came from?!?! Are you serious? Hmm. Well, there's the problem. If the casual user has decided to enter secret information into forms of unknown origin, then it doesn't really matter if the form's recipient uses a trusted key, since he doesn't know who the recipient is (until it's too late).

I'm at http://www.bank.com/ (note the lack of https) that I think is probably run by Bank Inc but I don't know for sure, since someone might be MitMing me, and I've been given no cert to check. My browser isn't displaying any trust info (such as a padlock icon) yet. Why would I enter any secrets onto that form? For all I know, that form is going to be sent (encrypted or unencrypted, I don't care) to www.thief.ru or some Javascript is capturing the info and sending it to http://www.bank.com/ even as I type stuff into it. I've been potentially compromised even before I click the submit button.

If I loaded the form from https://www.bank.com/ then at that point, the browser has already communicated to me how well I can trust (or not trust) that the page came from Bank Inc. That is the point where I can make a decision about whether or not to enter secrets into the form, or submit the form.

If you enter important secrets (ones where you really need authentication) into forms before you see padlock icons, then you've already lost. The browser's policies for dealing with certs, don't really matter, because no policy can save you.

Who cares if the connection which was used fetch the from the server was encrypted or not, the interesting part is what happens with the data that I entered to that form and then submitted over connection that I thought would be secure.

Who cares where the form came from?!?! Are you serious? Hmm. Well, there's the problem. If the casual user has decided to enter secret information into forms of unknown origin, then it doesn't really matter if the form's recipient uses a trusted key, since he doesn't know who the recipient is (until it's too late).

I'm at http://www.bank.com/ (note the lack of https) that I think is probably run by Bank Inc but I don't know for sure, since someone might be MitMing me, and I've been given no cert to check. My browser isn't displaying any trust info (such as a padlock icon) yet. Why would I enter any secrets onto that form? For all I know, that form is going to be sent (encrypted or unencrypted, I don't care) to www.thief.ru or some Javascript is capturing the info and sending it to http://www.bank.com/ even as I type stuff into it. I've been potentially compromised even before I click the submit button.

If I loaded the form from https://www.bank.com/ then at that point, the browser has already communicated to me how well I can trust (or not trust) that the page came from Bank Inc. That is the point where I can make a decision about whether or not to enter secrets into the form, or submit the form.

If you enter important secrets (ones where you really need authentication) into forms before you see padlock icons, then you've already lost. The browser's policies for dealing with certs, don't really matter, because no policy can save you.

And it uses telepathy to communicate back to the server, or does it just request https://bank.com/login?letter1=p&letter2=a&letter3=s&letter4=s and so on?

The point was that at some point along the line, a message is sent from your computer to the server, and any message a "graphics typepad" can send, so can a script, only 50000 times faster.

I'm still a bit puzzled about why they allow this kind of cross-site interaction in the security model. Shouldn't the sandbox be designed to not allow code on different html files to interact, or to only interact if they were loaded from the same site? And shouldn't the sandbox only allow TCP connections back to the site from which the code came from - and that includes connections created by loading URLs as well. I can see allowing redirections of the entire webpage (ie what is in the location bar), but that should flush all code/data out of memory, not allowing any interaction with the new site.

I guess that is still a problem if the user has a cookie that allows them to bypass a login screen and the script redirects them to http://bank.com/transferallcash?destacct=1234. There are probably solutions to this as well (don't allow GET/POST of form variables on redirects, don't allow redirecting at all across domains, don't design web apps with such simple interfaces that can be guessed).

Something about a trick where they hijack the ISP's DSN reference for the bank. So you can type http://mylocal.bank.com/ into your browser...and end up at a site that looks just like your bank's site, and can do man-in=the-middle interfacing with your bank account, so it can act properly.

That's why you type https://www.mybank.com into the browser window--the "s" means use SSL, and you'll see a dialog about bad certificates or whatever if somebody tries a man-in-the-middle attack. Now, some banks don't use https for their login page (they use a different method to encrypt just the login info), but the good ones do.

Personally, I avoid doing ANY banking over the net.

So what if some thugs make you withdraw money from the ATM at gunpoint? Did you shred your ATM card, too? Come on, there's a balance between risk and convenience, and saying "no" to online banking because of the very small risk of some new advanced attack is kind of silly.

I can see that argument with last years phish. Unfortunately, I've heard a few stories indicating that there are some phish of a new species arriving...and that they can fool "the very elect". Something about a trick where they hijack the ISP's DSN reference for the bank. So you can type http://mylocal.bank.com/ into your browser...and end up at a site that looks just like your bank's site, and can do man-in=the-middle interfacing with your bank account, so it can act properly.

Personally, I avoid doing ANY banking over the net. I don't think even the cautious and honorable ones are secure. I also don't think that most banks fall into the "cautious and honorable" category. Unfortunately, this doesn't totally remove me from danger, because the bank won't accept a "no internet business on my account" rule from me. None of the ones close enough to conveniently reach will.

The long and the short of it is...you can't reliably tell the phish from the bank. If banks are going to do business over the net, then they must be forced to accept the costs of phishing as a part of the cost of doing business. If they won't...most of my money is going to go looking for another home. (I keep telling myself I should do that anyway, because they barely pay sufficient interest in most years to cover inflation.)

Well, not very dangerous.
To affect someone directly, the client browser would have to be compromised to send doctored HTTP requests. If this happens to you, you're already 0wn0red, this little trick might at worst add insult to injury :)

But imagine this: luser.isp.net connects daily to bank.com through proxy.isp.net
evil.isp.net has tapped into the same LAN as Luser. evil.isp.net sends a doctored request to secure http://bank.com/login.php with exploit-redirection to insecure http://bank.com/demo.html, through proxy.isp.net
From now on, proxy.isp.net will serve demo.html to anyone who wants to access login.php. So luser happily types his real password and login into demo submit form (not looking at the lock icon) and happily clicks "submit", while evil.isp.net just sniffs the LAN and captures unencrypted POST request containing real password and login.

That's about as far as it goes. You can't do much if bank.com has DEMO with wide letters across the demo page. You can't redirect to offsite pages, and generally your possiblities are low...

Well, not very dangerous.
To affect someone directly, the client browser would have to be compromised to send doctored HTTP requests. If this happens to you, you're already 0wn0red, this little trick might at worst add insult to injury :)

But imagine this: luser.isp.net connects daily to bank.com through proxy.isp.net
evil.isp.net has tapped into the same LAN as Luser. evil.isp.net sends a doctored request to secure http://bank.com/login.php with exploit-redirection to insecure http://bank.com/demo.html, through proxy.isp.net
From now on, proxy.isp.net will serve demo.html to anyone who wants to access login.php. So luser happily types his real password and login into demo submit form (not looking at the lock icon) and happily clicks "submit", while evil.isp.net just sniffs the LAN and captures unencrypted POST request containing real password and login.

That's about as far as it goes. You can't do much if bank.com has DEMO with wide letters across the demo page. You can't redirect to offsite pages, and generally your possiblities are low...