[Cryptography] Fwd: OPENSSL FREAK

[WebDawg]

>
> Have a look at the protocol.  If a HELLO packet arrives, every
> implementation knows what to do.  If a USE AES256 arrives, every node knows
> what to do.
>
> If a SWITCH NOW packet arrives, what would we do?
>
> There is no answer to that.  There isn't even a SWITCH NOW packet...
>
> And, everyone's scratching their heads saying, wait, iang, you looney,
> that makes no sense at all.
>
>
>
> Now go helicopter:  There's a mechanism to PUT IN the algorithms and
> CHOOSE the algorithms.  But no mechanism to TAKE THEM OUT, nor to SWITCH.
>
> So obviously, uncontrolled growth was the order of the day, and at the
> micro level, down in the dirt, we get results like this:
>
>
>  The reason browsers kept the
>> export ciphers, is mostly attributed to their strive for 100%
>> compatibility with any legacy server out there.
>>
>
>
> The reason the browsers kept the export ciphers is because they haven't
> got a way to get rid of them *in the legacy servers*.
>


I guess the problem I see with it all is that the ineffective algorithms
are put into something that is depended on by a lot of people to secure a
lot of information in a modern/competitive world.  If someone needs to use
those ineffective algorithms in their lawful version of whatever world they
are in, it should be the work of that group to provide backwards capability
and provide patches/whatever to provide it.

It keeps getting mentioned that they are put in there so people can keep
interfacing to old outdated servers and services also, but what the heck?
When has it ever been common place to keep something similar like a
vulnerable script/code interpreter around so things just "work"?

Why is upgrading a protocol of a network infrastructure any different then
the necessity of patching vulnerabilities in software code?  Who cares if
it breaks compatibility, it needs fixed.

I think it is even worse to do something like this, with a piece of
software like this, because its primary function IS security/encryption.
It is still a piece of code that is broke, it is just broke in a different
way that does not need to be fixed, but pruned.

Even if a SWITCH or TAKE OUT was put into the code it is just another place
to potentially exploit.  The TAKE OUT sounds nice, but I would think in a
CHOOSE, it would just remove the rest anyways.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150327/696de3e1/attachment.html>