MozillaZine

"Secure Connection Failed" problem

Discussion about Seamonkey builds
johndoe32102002
 
Posts: 7
Joined: October 21st, 2007, 2:35 am

Post Posted November 1st, 2007, 3:08 pm

FIREFOX DEVELOPERS -- THIS IS A BUG! PLEASE FIX IT!

I can not get to the following website, https://search.auburn.edu, because Firefox chooses to BLOCK and CENSOR websites based on the security of their SSL certificate. Please fix this in the next Firefox version.

johndoe32102002
 
Posts: 7
Joined: October 21st, 2007, 2:35 am

Post Posted November 1st, 2007, 3:08 pm


Andy Boze

User avatar
 
Posts: 2703
Joined: June 30th, 2005, 9:53 pm
Location: South Bend, IN

Post Posted November 1st, 2007, 3:28 pm

Since this is a support forum for SeaMonkey, I can't tell you exactly what to do with Firefox. The certificate expired in 2001 for https://search.auburn.edu/ . You can add an exception for it in your certificates manager. If I were you, though, I'd contact the folks at Auburn's OIT, http://www.auburn.edu/oit/ , to find out if that server is still meant to be used. Maybe you should be using this instead, http://www.auburn.edu/main/ldap.html . Just a thought.
But then again, I may be wrong.

johndoe32102002
 
Posts: 7
Joined: October 21st, 2007, 2:35 am

Post Posted January 27th, 2009, 7:07 pm

Seamonkey and Firefox still block HTTPS/SSL pages with invalid certificates -- Just try to access your 2Wire router: https://192.168.1.1 or https://192.168.1.100 to find out you cannot!

LoRd_MuldeR

User avatar
 
Posts: 202
Joined: January 21st, 2007, 2:26 pm

Post Posted January 27th, 2009, 8:25 pm

johndoe32102002 wrote:Seamonkey and Firefox still block HTTPS/SSL pages with invalid certificates -- Just try to access your 2Wire router: https://192.168.1.1 or https://192.168.1.100 to find out you cannot!


That's because a "secure" connection is absolutely useless without a valid certificate!

If you can't ensure that the person/computer one the other side really is the person/computer it pretends to be, you don't need to encrypt your data.
The person/computer you are connected to through the secure connection might very well be the attacker!

So the only sane thing you can do as a web-browser is preventing any "secure" connection, unless the target host can identify itself with a valid certificate.
A simple message box with an "ignore" button is insufficient, as the normal user wouldn't understand what an invalid certificate actually means.
The user probably would choose "ignore" overhasty, which leads to really dangerous security problems!

Advanced users who know what they are doing are still able to put "invalid" certificates to their "Exceptions" list. Where is the problem?
The only reason I opened this Thread was that the "Add Exception" option was still missing at that time...

BenoitRen

User avatar
 
Posts: 5921
Joined: April 11th, 2004, 10:20 am
Location: Belgium

Post Posted January 28th, 2009, 9:03 am

Sending unencrypted login data to a site you trust is better than sending encrypted login data to a site that I trust with a self-signed certificate?

LoRd_MuldeR

User avatar
 
Posts: 202
Joined: January 21st, 2007, 2:26 pm

Post Posted January 28th, 2009, 3:58 pm

BenoitRen wrote:Sending unencrypted login data to a site you trust is better than sending encrypted login data to a site that I trust with a self-signed certificate?


Sending your login data (or whatever data) through an encrypted connection is as insecure as not encrypting your data at all, unless you can identify the person/machine on the other side of the "secure" connection. And that's exactly what a certificate is good for. An attacker can very well pretend to be a "secure" host! You have no way to check the authenticity of your communication partner, except for checking his certificate. If you don't do that, you might be establishing the encrypted connection directly to the attacker's machine and you won't even notice. However if you know what you are doing and if you are aware of all the risks, then you can still add the invalid (or "self-signed") certificate to your "Exception" list - at any time. But a browser really shouldn't pretend a "secure" connection to the user when it's not secure at all in fact...

BenoitRen

User avatar
 
Posts: 5921
Joined: April 11th, 2004, 10:20 am
Location: Belgium

Post Posted January 29th, 2009, 8:35 am

If I'm sending data to a site through a non-secure connection, people that get a hold of the data in the middle can read it. If the connection is secure, they can't. So again, how is a secure connection with self-signed certificate, less safe than no secure connection at all?

Philip Chee

User avatar
 
Posts: 6457
Joined: March 1st, 2005, 3:03 pm

Post Posted January 29th, 2009, 11:29 am

BenoitRen wrote:If I'm sending data to a site through a non-secure connection, people that get a hold of the data in the middle can read it. If the connection is secure, they can't. So again, how is a secure connection with self-signed certificate, less safe than no secure connection at all?

It gives the user a false sense of security, and they might send sensitive information over such a link that they might otherwise not have.

Phil

jasonb
Moderator

User avatar
 
Posts: 1104
Joined: October 18th, 2007, 1:52 pm

Post Posted January 29th, 2009, 12:14 pm

Sending your login data (or whatever data) through an encrypted connection is as insecure as not encrypting your data at all

I disagree. That's only true if the trust of the receiver is in question. Sending encrypted is still better than unencrypted if you want to prevent anybody between you and the receiver from sniffing your data...
(I actually joined in 2002 and made 6,093 posts, now shown under "old jasonb", before the site tried to kill me off...)

LoRd_MuldeR

User avatar
 
Posts: 202
Joined: January 21st, 2007, 2:26 pm

Post Posted January 30th, 2009, 6:58 am

jasonb wrote:
Sending your login data (or whatever data) through an encrypted connection is as insecure as not encrypting your data at all

I disagree. That's only true if the trust of the receiver is in question.


And the trust of the receiver always is in question, unless it provides a valid certificate (signed by an authority you trust).


jasonb wrote:Sending encrypted is still better than unencrypted if you want to prevent anybody between you and the receiver from sniffing your data...


Wrong. Unless you verify the authenticity of the receiver with a valid certificate, "anybody between you and the receiver" can pretend to be the receiver.
So possibly you'd establish the "secure" connection right to the attackers machine. That's called a "man in the middle" attack.


BenoitRen wrote:If I'm sending data to a site through a non-secure connection, people that get a hold of the data in the middle can read it.


Again wrong. And again the "man in the middle" attack is the problem.
People in the middle can pretend to be the receiver and you can NOT verify their identity without a valid certificate (signed by an authority you trust).

So you may agree on a "secret" key with somebody you think is the receiver, but who is the attacker in fact.
In the next step the attacker pretends to be you an establishes an encrypted connection to the actual receiver. Whoops, attack applied successfully!
The connection is still encrypted (feels like "secure"), but isn't secure at all, because the attacker knows the secret key(s) and can read everything.

Please get rid of the naive idea that "encrypted" equals "secure", which definitely is wrong in reality...

In short: No valid certificate -> No authentication of the communication partner possible -> No secure connection


Philip Chee wrote:It gives the user a false sense of security, and they might send sensitive information over such a link that they might otherwise not have.


Very right! :)



That info is from Wikipedia:

SSL ist ohne eine zertifikatsbasierte Authentifizierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt: Ist der Man-In-The-Middle vor der Übergabe des Schlüssels aktiv, kann er mit beiden Seiten den Schlüssel tauschen und so den gesamten Datenverkehr im Klartext mitschneiden.


It's from the German article, but maybe you can understand it anyway or translate it ;)

In basically says that SSL does NOT work without certificate-based authentication, because of the Man-In-The-Middle attack problem...

BenoitRen

User avatar
 
Posts: 5921
Joined: April 11th, 2004, 10:20 am
Location: Belgium

Post Posted January 30th, 2009, 9:10 am

Wait, you're saying that if I transmit data over a non-secure connection, and someone in the middle gets a hold of it, (s)he can't read it?

By the way, I don't necessarily trust the authorities, like VeriSign. They don't do enough checking.

jasonb
Moderator

User avatar
 
Posts: 1104
Joined: October 18th, 2007, 1:52 pm

Post Posted January 30th, 2009, 9:12 am

LoRd_MuldeR wrote:And the trust of the receiver always is in question, unless it provides a valid certificate (signed by an authority you trust).

I'll disagree with this too - as an absolute statement of fact. If I have two computers sitting in a lab, not connected to the Internet, and I'm sending from one to the other - I know for a certainty what the receiving machine is and what the sender is. There are other situations too. I could be sending to a buddy of mine half-way around the world. We're on the phone, and I've been told what that computer's IP address is. I may not be absolutely, completely certain that when I go to that IP I'm actually hitting the machine I've been told about, but for all intents and purposes I am. Any other edge case - where somebody knows to, and wants to, redirect me somewhere else - is the height of paranoia, especially if his computer isn't anything important, and one that's just been set up. (It's quite improbable that anybody would bother with a man in the middle for something like that.) That may be fine to consider when security is vitally important - but not for everyday life.

LoRd_MuldeR wrote:Wrong. Unless you verify the authenticity of the receiver with a valid certificate, "anybody between you and the receiver" can pretend to be the receiver.
So possibly you'd establish the "secure" connection right to the attackers machine. That's called a "man in the middle" attack.

I do know what the term is. <grin> You may be able to argue that an encrypted connection is no better than a non-encrypted connection in some cases (and not all of them) - but you certainly can't argue that it's any worse. Assuming, that is, that the sender takes on the responsibility and knowledge for things that "might" be happening at the receiving end - so that there are no false senses of security.

BenotRen wrote:Wait, you're saying that if I transmit data over a non-secure connection, and someone in the middle gets a hold of it, (s)he can't read it?

No, they're not saying that. If you transmit data over a non-secure connection, and somebody gets hold of it, it will be in plain text and quite readable. If you transmit over a secure connection, you negate any possibility of that happening. This is what makes the argument that, everything being equal, a non-secure connection is no worse than a secure connection somewhat misleading.

Let's say that I know that the receiver has an invalid certificate. I have two choices. Either do nothing at all, or accept the risk. If I accept the risk, I would rather also transmit via encryption. If I don't then I needlessly accept the additional risk of the non-verifiable receiver as well as somebody else sniffing things. Why should I be forced to accept both risks when I only need to accept one? If we assign values of risk here, and give both man in the middle and sniffing equal weight (x), I'd rather assume a risk of x than a risk of 2x. (Assuming that I choose to go ahead with a transaction in the first place.)

The problem with this discussion is that one side is talking about theoretical security (which I also agree with, just not in the context of my particular argument), the other is talking about practical security once you hit a site without the proper certificate - and then decide what's better to do at that point (which I'm arguing for). I think that any dissension here is simply because we're arguing about different things. (At least I'm hoping that we are.) What should really be discussed is - what happens with SeaMonkey. I.e. What should it allow the user to do when it hits a site with an invalid certificate. There are really only a few choices: Always allow it, always disallow it, or ask the user what to do in some way (ask each time, remembered site preferences, remember global preferences, etc.).

BenoitRen wrote:By the way, I don't necessarily trust the authorities, like VeriSign. They don't do enough checking.

Do you keep all of your money in a sock buried in the woods somewhere? LOL (Sorry, I couldn't resist. The image just popped into my head.) On a more serious note, nothing is absolutely secure. (I don't know enough about the certificate authorities to actually comment.)
(I actually joined in 2002 and made 6,093 posts, now shown under "old jasonb", before the site tried to kill me off...)

LoRd_MuldeR

User avatar
 
Posts: 202
Joined: January 21st, 2007, 2:26 pm

Post Posted January 30th, 2009, 9:35 am

jasonb wrote:
LoRd_MuldeR wrote:And the trust of the receiver always is in question, unless it provides a valid certificate (signed by an authority you trust).

I'll disagree with this too - as an absolute statement of fact. If I have two computers sitting in a lab, not connected to the Internet, and I'm sending from one to the other - I know for a certainly what the receiving machine is and what the sender is. There are other situations too. I could be sending to a buddy of mine half-way around the world. We're on the phone, and I've been told what that computer's IP address is. I may not be absolutely, completely certain that when I go to that IP I'm actually hitting the machine I've been told about, but for all intents and purposes I am. Any other edge case - where somebody knows to, and wants to, redirect me somewhere else is the height of paranoia - especially if his computer isn't anything important, and one that's just been set up. (It's quite improbably that anybody would bother with a man in the middle on something like that). That may be fine to consider when security is vitally important - but not for everyday life.


Never heard of IP Spoofing, eh?

Please get rid of the idea that the IP protocol gives you any (security) guarantees of any kind [-o<

Any machine on the way that your IP packets travel can pretend to be the target machine easily.
Even machines that your packets wouldn't pass normally can spoof the target IP address and then redirect your IP packets to their own address.
Also note that thanks to Network Address Translation (NAT) there even is no "one machine - one IP address" relation any more!
And no, even in your local lab (not connected to the internet) an attacker may sit on the neighboring table and spoof the IP of your target computer...

Conclusion: An IP address is 100% useless for authentication!


jasonb wrote:You may be able to argue that an encrypted connection is no better than a non-encrypted connection in some practical cases (or all purely theoretical cases) - but you certainly can't argue that it's any worse.


It's worse in the sense that it pretends a "security" to the user that doesn't exist!

Also encryption takes additional CPU overhead, which is a complete waste, if you did not do the initial handshake properly (which includes a valid certificate), as you'll get encryption but no true security from it!


jasonb wrote:Let's say that I know that the receiver has an invalid certificate. I have two choices. Either do nothing at all, or accept the risk. If I accept the risk, I would rather also transmit via encryption. If I don't then I needlessly accept the additional risk of the non-verifiable receiver as well as a man in the middle attack. Why should I be forced to accept both risks when I only need to accept one? If we assign values of risk here, and give both man in the middle and sniffing equal weight (x), I'd rather assume a risk of x than a risk of 2x. (Assuming that I choose to go ahead with a transaction in the first place.)


You are not forced to do anything. If you understand what an invalid certificate means (that means you are aware that the connection will not be "secure" in fact) then you can add the "invalid" certificate to your Exception list and proceed. SeaMonkey doesn't prevent you from doing that! But that must not happen automatically for the reasons explained enough. Also that feature of SeaMonkey shouldn't be reachable too easy, because that would encourage the users to take security risks they don't even understand. People just shouldn't accept invalid certificated, unless they know exactly what that means.

If you understand what it means, then I'm the very last person on earth telling you that you aren't allowed to accept invalid certificates. I do it very often too :D


BenoitRen wrote:Wait, you're saying that if I transmit data over a non-secure connection, and someone in the middle gets a hold of it, (s)he can't read it?


The person in the middle of your none-encrypted connection can read the data just as easily as any Man-In-The-Middle attacker in your wrongly (without valid cert) establish encrypted connection.

Conclusion: Both kinds of connections must be considered none-secure! Only the the encrypted one pretends a kind of security that it doesn't offer in fact...


BenoitRen wrote:By the way, I don't necessarily trust the authorities, like VeriSign. They don't do enough checking.


The trust of public-key infrastructures is another topic :roll:

But fact is that "secure" connections on the internet aren't possible without an public-key infrastructure (unless you meet any internet user in reality and exchange a secret key directly from person to person, which means that you need to exchange n^2 keys, where n = 4.000.000.000 at the moment - good luck ^^)


BenoitRen wrote:I don't know enough about the certificate authorities to actually comment


Then you should read about RSA (or asynchronous encryption in general), about Hash functions (e.g. SHA1) and how digital signatures can be built from that.
Once you got that, you can understand how certificates work in fact. Then finally you can read up on public-key infrastructures...
Last edited by LoRd_MuldeR on January 30th, 2009, 10:07 am, edited 2 times in total.

Philip Chee

User avatar
 
Posts: 6457
Joined: March 1st, 2005, 3:03 pm

Post Posted January 30th, 2009, 9:59 am

jasonb wrote:Do you keep all of your money in a sock buried in the woods somewhere? LOL (Sorry, I couldn't resist. The image just popped into my head.) On a more serious note, nothing is absolutely secure. (I don't know enough about the certificate authorities to actually comment.)

Off topic I'm sure, but this was probably a better strategy than to invest with Bernard L. Madoff Investment Securities LLC.

Phil

Return to SeaMonkey Builds


Who is online

Users browsing this forum: No registered users and 1 guest