4 ms·

I think you would still have to count that as a security failure. For one, you don't know why there is ssl and non-ssl - there could be content that's available

by klync 16y ago

I think you would still have to count that as a security failure. For one, you don't know why there is ssl and non-ssl - there could be content that's available over ssl and/or via login which you don't see using the "public" http url schema. The server could be set up to make this transparent to you, making it appear that ssl is superfluous. Second, even if that's the case, a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting.

rlpb 16y ago
> ...a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting. That depends on what is required of the SSL implementation. A self-signed cert which the client cannot verify still provides some protection. It is MITM-able, but casual snooping is prevented. If this is the specification, then this implementation is not broken. Put it this way. Forget the specifics of SSL for a moment. If unencrypted data is acceptable, then in what way is having the option of weak-but-slightly-better encryption suddenly "broken"? This analysis is flawed because it assumes that strong security was required by all who use SSL at all. Many installations use a self-signed SSL cert by default. These default configurations often remain when security is not required and therefore not configured further. I suspect that this skews the figures far enough to make this sort of analysis meaningless.
- klync 16y ago
  Hey rlpb, Sorry, I tried to reply to your post about 4 times yesterday, and it never went through for some reason. I agree with what you're saying about self-signed certs being not necessarily broken. Maybe I mis-read your original message, but what I was objecting to was the idea that a site that apparently has the same content available over http and [broken] https is not a problem; I'm saying that broken is broken regardless of the content it's protecting. As to what constitutes "broken" ... I think we agree - that would be SSL. :P

by klync 16y ago

rlpb 16y ago

> ...a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting. That depends on what is required of the SSL implementation. A self-signed cert which the client cannot verify still provides some protection. It is MITM-able, but casual snooping is prevented. If this is the specification, then this implementation is not broken. Put it this way. Forget the specifics of SSL for a moment. If unencrypted data is acceptable, then in what way is having the option of weak-but-slightly-better encryption suddenly "broken"? This analysis is flawed because it assumes that strong security was required by all who use SSL at all. Many installations use a self-signed SSL cert by default. These default configurations often remain when security is not required and therefore not configured further. I suspect that this skews the figures far enough to make this sort of analysis meaningless.

klync 16y ago
Hey rlpb, Sorry, I tried to reply to your post about 4 times yesterday, and it never went through for some reason. I agree with what you're saying about self-signed certs being not necessarily broken. Maybe I mis-read your original message, but what I was objecting to was the idea that a site that apparently has the same content available over http and [broken] https is not a problem; I'm saying that broken is broken regardless of the content it's protecting. As to what constitutes "broken" ... I think we agree - that would be SSL. :P