[ALUG] Mozilla will obsolete HTTP

[Andreas Tauscher]

> Mozilla's and Google's approach is similar to how email currently 
> operates. The postmaster(who knows what they're doing) can easily 
> control/force users to use SSL/TLS OR set parameters to
> delay/reject/etc emails from misconfigured servers. But with HTTP the
> only way of forcing the webmaster's hand is from the client(the
> browser). As long as the standards these browsers are enforcing are
> the same standards developed by the Internet community through public
> consensus.

What is done.
Everything is discussed in the IETF and the W3C. Most is discussed on
mailinglists. What is discussed in meetings the minutes are published
then. All the drafts are published.

> [1] The Safety in mind here is the kind of safety that not anyone
> you pissed off can Google a tutorial and easily compromise your 
> security/privacy, or any kid who knows how to use Wireshark can end
> up causing some serious damage.

Really "fun" it becomes when somebody trying metasploit in a real
network: Smoking runis: I did nothing I startet only this CD and clicked
a little bit through the menues.

> So at least for me I see what they are trying to do is a good start.

> Safety from Governments and these 3-letter Agencies(as Richard call 
> them) that have backdoors in OpenSSL and run CAs all over the World
> will remain political and a fight for another day, if they want to
> compromise your privacy they can and will do it regardless. In other
> words you're (as Alan put it)screwed.

In OpenSSL is audited at the moment. What is already done and finished
in February this year: The entire source code was reformatted to make it
easier readable. Results are expected this summer:
https://cryptoservices.github.io/openssl/2015/03/09/openssl-audit.html

I don't think there will be backdoors found in OpenSSL. What is in
OpenSSL: A lot of legacy crap.

Hardbleed was a serious bug. But in such an project having only one full
time developer an financial not best set up........
Or the Debian disaster with ssh keys: The packet maintainers thought
they make it a little bit more efficient on not so powerful hardware.
The result was: ssh-keygen genereated only 65535 different keys. From
there comes the packet openssh-blacklist.
Coding encryption is not easy. There are many examples how encryption of
secure systems was broken with side channel attacks. Not the algorithm
was the problem: The implementation.

What No Such Agency did: They have taken influence on the definition
process for encryption algorithms to weaken them.
When I know where a weakness is hidden it is easier for me to break a
encryption. They maybe can not break it today, but in a few years they
might have.
Suspicious NIST/FIPS curves have been already banned.

> PS. I see there's a lot of interest on this subject may be we should
> put it in schedule of future discussions(meets) and may be Andreas
> and myself will talk about security/encryption/cryptography before
> it.

Let's meet end of the week and doing some brainstorming.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.habari.co.tz/pipermail/linux/attachments/20150504/cb7bf3dc/attachment-0001.pgp>