KDEPIM 4.6 prob^Wimpressions
1i5t5.duncan at cox.net
Tue Jul 26 21:32:00 BST 2011
J posted on Tue, 26 Jul 2011 15:31:03 -0400 as excerpted:
>> If you don't mind, I have one more questions on this. How bad is the
>> security impact? For example, my online banking site is
>> https://banking.postbank.de , probably one of the most used banking
>> sites in Germany. How big is the risk of using it? Would you do this?
>> What can be done to minimize the risk? Other than using Firefox and
>> simply not seeing the warning dialog :)
> Overall the security isn't a big issue, but the "trust" that comes from
> the certificate is the issue. The warning message means that the
> certificate presented could not be matched up to the corporation (in
> this case the bank) using the available chain of "trusted" certificates
> that already exist in the browser or presented by the web server. The
> encryption is still there and does it's job, you just cannot be sure
> that the bank actually sent this certificate to you or is some "man in
> the middle" sent it instead.
There's a couple ways around that.
One is verifying the bank cert via other methods. Call them up and ask
them to put the cert on a USB stick or something and send it to you, or
visit a branch and ask there.
A different method of doing the same thing would be to surf to the site
via different connections (or ask someone else to verify the info from
their connection) so someone would have to be MitM-ing all of them in
ordered to successfully deceive you. I did this when my bank had some
certificate issue of some sort at one point, posting a request for people
to verify it from other locations, which they did.
The other method is to simply take your chances the first time
(preferably do it over a wired connection that you trust, not over a wifi
or from the library or whatever, no use taking needless risks) and
permanently accept the certificate, then rely on the notification you'd
get if it changed to detect interference from then on. As long as you
aren't doing something stupid like verifying it for the first time over
public wifi at the airport, the chances of the first connection being a
bad one are pretty slim.
This "accept it the first time, then don't worry about it unless it
changes" method, is pretty much the way SSH key authentication works.
You get prompted the first time and generally assume everything's fine (a
few folks verify the fingerprint via other means too, but not many), and
don't worry about it after that unless you get prompted again, meaning
the certificate at the other end isn't the one that was expected, so
there's a good chance it's not the other end after all (unless of course
you know that they changed their cert, perhaps because you did it as the
admin, yourself, or it can also happen if the fingerprint info at your
end got deleted.)
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde