On 5/22/06, Brian Dessent [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On Mon, 22 May 2006 12:02:23 EDT, Dude VanWinkle said:
DNS foo to the client, how easy is that? Would you have to get the
upstream DNS server to cache your bogus entry?
You'd be *amazed* how many are still
On 5/23/06, Brian Eaton [EMAIL PROTECTED] wrote:
On 5/23/06, Dude VanWinkle [EMAIL PROTECTED] wrote:
I guess you would hijack their machines with a bug that would edit the
local cache, refresh the cache, then report to you about the websites
the victim's machine had visited, and you could
* Michal Zalewski:
SSL Mistake #2 - Assuming a signed certificate is the right
certificate
I don't understand what you're trying to say here: it seems to me that
you're suggesting that allowing all users with a valid certificate the
same privileges is a bad idea. Probably, but this has
Am Sonntag 21 Mai 2006 17:26 schrieb Ginsu Rabbit:
Five Ways to Screw Up SSL
Let me add:
http://uin4d.de/~thetom/blog/index.php?/archives/9-How-secure-is-SSLTLS-in-Real-Life.html
--
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF
Why would it matter who signed it? As long as the data is encrypted as
it travels over the internet, I am happy.
Because encrypted is only half the battle. Trusting that $entity is
really $entity is the other half.
Most end-users aren't smart enough to verify that when they hit
On 5/21/06, Thierry Zoller [EMAIL PROTECTED] wrote:
Dear Dude VanWinkle,
DV Why would it matter who signed it? As long as the data is encrypted as
DV it travels over the internet, I am happy.
Why would it matter who signed it? I am happy to handle the ssl
handshake mitm for you. All your
On 5/22/06, Michael Holstein [EMAIL PROTECTED] wrote:
I was referring to the CA that signs it. It was implied that
freessl.com, who gives out trial certificates, is an unreliable CA. I
do not understand why their certs would be any less valid than
anothers.
Not less valid, less trusted. SSL
On Mon, 22 May 2006 12:02:23 EDT, Dude VanWinkle said:
DNS foo to the client, how easy is that? Would you have to get the
upstream DNS server to cache your bogus entry?
You'd be *amazed* how many are still running BIND 4 or 8
pgpcnogxSyYAE.pgp
Description: PGP signature
Five Ways to Screw Up SSL
SSL is a wonderful protocol, but it is frequently used
badly. This note is intended to point out some of the more
common errors made by applications using SSL.
This checklist should be useful for application developers,
system administrators, and the occasional
On Sun, 21 May 2006, Ginsu Rabbit wrote:
You claim that this is a practical checklist for five very common problems
with SSL deployments... but to me, they seem to be arbitrarily chosen,
partly inaccurate (see #3), and otherwise very much random.
SSL Mistake #1 - Trusting too many Certificate
Michal Zalewski [EMAIL PROTECTED] wrote:
You claim that this is a practical checklist for five very common problems
with SSL deployments... but to me, they seem to be arbitrarily chosen,
partly inaccurate (see #3), and otherwise very much random.
Inaccurate? Not to my knowledge. Incomplete,
On 5/21/06, Ginsu Rabbit [EMAIL PROTECTED] wrote:
Stuff
The only thing that matters about SSL is the fact that it encrypts the
data. You can reduce your checklist to:
-
1: Make sure you use a good cipher |
Dear Dude VanWinkle,
DV Why would it matter who signed it? As long as the data is encrypted as
DV it travels over the internet, I am happy.
Why would it matter who signed it? I am happy to handle the ssl
handshake mitm for you. All your encrypted data is belong to me.
--
http://secdev.zoller.lu
13 matches
Mail list logo
