[ALUG] Mozilla will obsolete HTTP

Tim Schofield tim.schofield1960 at gmail.com
Mon May 4 12:09:38 EAT 2015


Couldn't agree more about paypal, they are incompetent thieves. I
closed my account years ago after they tried to steal hundreds of
pounds of my money!

I know there are great open source tools for securing your web site -
as I said your technical knowledge of such things is light years ahead
of mine. My point is whether it is the job of the browser companies to
force that upon us. I dislike the idea that Google/Mozilla etc will
deliberately break web sites that aren't setup as they want them
setup. If webmasters don't secure their sites properly surely that
should be up to them? If I want to leave my front door unlocked then I
can, there is no law to stop to me, and there shouldn't be. If I get
robbed then it is my fault. Advising me to lock the door should be
enough, just as advising me to encrypt should be enough. It's not the
need for encryption that bothers me, it is the forcing it upon people.

Should a company intranet server really have to pay to authenticate
itself? Seems crazy to me, I know many intranets where the clients
aren't even connected to the internet itself.

Most sites will benefit from encryption, but actually very few really
need to authenticate themselves. Shouldn't a simple form of self
certification be sufficient?

On 3 May 2015 at 17:24, Andreas Tauscher via Linux
<linux at lists.habari.co.tz> wrote:
> And when I'm already in the mood bashing. Another one on paypal:
>
> In 2010 I ordered a few gadgets. Payable with paypal. My problem was: I
> could not change the shipping address from Germany to Tanzania.
> After several mails to paypal support and getting useless answers I had
> an closer look on the web forms.
> Plenty of hidden elements, and some crappy, obfuscated java script.
> Firebug, a few changes in the page code and I had my shipping address in TZ.
> Verification done on the client side? WTF?
> paypal was informed about this problem and the proof was my changed
> profile holding a shipping address which should not be possible.
> They ignored it. Never got any reply on this issue and it took nearly
> two years until this bastards fixed it.
> And such (fill in very strong word) idiots I should trust in any way?
>
> When they put the key under the doormat encryption is snakeoil.
>
> But back to the topic:
>
> With DANE and DNSSEC I have powerful tools to get more control and I
> become more independent from more or less reliable institutions.
> In a DNSSEC signed zone I can safe publish information like
> fingerprints, public keys, certificates and plenty of configuration stuff.
> If somebody is interested: Do on your gateway or name server a ngrep on
> port 53 (Oh, and if sometimes things are loading slow check if port 53
> is open for UDP and TCP. Nowadays DNS replies can be bigger than 512Byte
> and then DNS switches to TCP). You will see queries the names starting
> with _ (absolutely forbidden for hostnames!) all this are queries for
> configurations published in the DNS. Windows Server 2012 for example is
> using it a lot. Have a look on a DC in the DNS. You will find there
> zones like _tcp _udp _msdcs.
>
> In a net without DNSSEC I can do really funny things with a little bit
> DNS spoofing. Funny or not depends on the point of view. The victim
> surely will not be amused.
>
> The open source community provided now all bolts and nuts. It is now on
> the software developers to implement all this gadgets to make
> communication more secure and regaining control.
>
> But: It will get tough for some guys. Proper set up encryption on a
> server is not a piece of cake. It is more than only copying a key and
> certificate file. If something is not working debugging needs a
> understanding what is going on and how all the systems are playing together.
>
> Andreas
>
>
>
> _______________________________________________
> The Arusha Linux User Group: http://unix.or.tz
> Linux mailing list
> Linux at lists.habari.co.tz
> http://lists.habari.co.tz/cgi-bin/mailman/listinfo/linux
>
> The Arusha LUG mailing list is generously hosted by Habari Node Ltd: http://www.habari.co.tz/
>
> The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.



-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/


More information about the Linux mailing list