I use the "blue-browser" once in a while and can attest that no, there is no https "always on" setting or addin. I must admit the eff addin has made life online worth living for me. Still, such knowledge isn't worth jack if you don't use it properly and a lot of it is rendered useless because it is not asymmetric. I still don't know how to secure just one half of a conversation and still have that conversation. Maybe high security and "on by default" encryption should become the new standard. I used to have pgp on all my email but it got redundant when less than 1% of my correspondents had it or understood it. Making people secure without an air of paranoia is next to impossible.
Sincerely James Makumbi Billable Ltd 0790834364 / 0712780817 http://www.coderbits.com/jmakumbi http//:ug.LinkedIn.com/in/jmakumbi On Jun 10, 2013 2:05 AM, "joachim Gwoke" <[email protected]> wrote: > Message: 2 > Date: Sat, 8 Jun 2013 12:58:53 +0200 > From: Benjamin Tayehanpour <[email protected]> > To: Uganda Linux User Group <[email protected]> > Subject: Re: [LUG] CERT was [NITA site hacked!] > Message-ID: > <cal-vo6lpwgyixqh-wa+xuxeybtzbdqiynh8-8codq2gd8gx...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > HTTPS is effective only when fully and properly implemented. > For this to > happen, the client (and the user) must be aware of how HTTPS > works, and how > things are supposed to behave when everything is as it > should. > > I can, in practice, see three obvious weaknesses, and > therefore three ways > to defeat HTTPS as a method of securing a connection to a > web service. > There are others, both more effective and less so, but these > are the most > obvious ones: > > 1. A MITM attack with a self-signed certificate. This will > generate a > security alert in the user's browser, but many users are > ignorant and will > ignore this. This is the least effective and most > conspicuous attack, but > it is cheap and easy. > > 2. A MITM attack with no certificate at all. Let me > elaborate on this. When > a user wants to go to e. g. Twitter, she usually types > "twitter.com" into > the address field. Due to the mechanics of intelligent > autocompletion > (which I detest, by the way, due to issues like these), this > will, in > normal cases, take her to an HTTP page, which will redirect > her to the > HTTPS page. If an MITM attack is performed, the attacker > could simply skip > the redirection step and manufacture a passable replica of > the Twitter > login page which goes over HTTP. No certificate security > warning will be > shown, because there is no secure connection to begin with. > On some > browsers this will generate a "you are sending form data > unencrypted over > the Internet, you moron" warning, but in most browsers this > dialog has been > disabled. This is as easy as attack 1, but should have a > higher rate of > success. This will, of course, not be effective at all if > the user > explicitely requests an HTTPS connection. Not many do, > though. Sadly, most > people expect technology to do their thinking for them. > > 3. A MITM attack with a perfectly valid certificate from a > compromised > certificate authority. Compromising a CA is tricky business, > but it is > certainly not unheard of. The point here is that *any* > recognised > Certificate Authority can issue a valid certificate for, > say, twitter.com. > If *one* CA is compromised, and there are loads of CAs based > in shady > countries with patchy legal protection from the state, the > entire chain of > trust is broken until that CA has had its root certificate > revoked and that > revokation has been pushed to all clients. This is a > fundamental weakness > of the CA web-of-trust system in place now, and there is > little one can do > about it. Luckily, when DNSsec and DANE is finally > implemented, we'll be > rid of central CAs entirely, the actual validation going > through DNS > instead. This means two things: a) The above mentioned > weakness will be > eliminated, and b) Certificates will be completely free to > implement for > domain name owners, as the process of setting one up will be > a routine DNS > procedure. When that time comes, there will be no valid > excuses whatsoever > not to implement connection encryption. > > Not that there are any valid excuses for that now, mind. Not > implementing > TLS ("HTTPS") is despicable. I don't believe the surveillance of social media here is worth Government's time and resources. Like I said elsewhere we do not have the critical mass to threaten the powers that be. Even with Egypt most of the planning efforts and action was done offline. I doubt 300,000 or so people online warming seats would change much(most are minding their own..). Our 'minders' are better off focusing their efforts offline. On enforcing HTTPS the guys at EFF have a browser add-in for that, chrome/chromium and FF have add-ins doing the same, by now the 'blue-browser' must be having such capabilities as well. regards Joachim _______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ 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.
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ 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.
