On 23/02/11 20:56, Andres Perera wrote: > On Wed, Feb 23, 2011 at 5:57 PM, Hugo Osvaldo Barrera > <h...@osvaldobarrera.com.ar> wrote: >> On 02/23/2011 10:35 AM, Chris Bennett wrote: >>>> They're a fucking disaster security-wise. >>> >>> +1 >>> >>>> In general, blocking javascript won't get you too far, because most of the >>>> issues are not in the client, but rather in the use that's made of >>>> javascript. >>> >>> I basically block javascript to stop some adveritising and keep some sites >>> from crashing firefox. >>> But many, many sites require javascript to even login (i.e. many bank >>> websites!) >>> >>>> - trying to do https and having to deal with corrupt certificate >>>> authorities >>>> that don't guarantee too much in the end. >>> >>> CA's cannot be trusted to even pay attention to carefully securing your >>> certificate. >>> Here in the US, the government can simply ask for your certificate and get >>> it ( and possibly even use it to impersonate you) >>> >>> I sign my own certificates, post a copy of serial number and correct name >>> and IP address on my websites using them. I explain to every customer that >>> I do not trust external CA's and that I am only using https for encryption >>> of passwords and paid content. >>> No one has complained.
A simple man-in-the middle of that site, and replacing it's content would open the door for every site you refer to. If it's an SSL website, you're in and endless loop without a CA or trusted third party. >>> >>> Some have told me that I am risking a man-in-the-middle attack. Perhaps. >>> But I see little reason to trust the CA man-at-the-end! >>> >>> Chris Bennett >>> >> >> Supposing that's the case, the government can just request a CA a >> certificate for your domain, and do a man-in-the middle. User's won't >> get any prompt for invalid cert, and the same "vulnerability" you >> described using still exists. >> > > that's flawed because you're assuming his users are trusting equifax, > cacert.org, and the countless of others that get bundled in certs packages for > unix, or worse, his users are ussing a browser that comes bundled with its own > set of certs and ssl library (firefox). That means you'd have to physically give the certificate to every user, with no trusted authority, or trusted third party, you have no way of establishing a secure (authenticated) communication, except physically being with that person. How do you then pay your taxes? Check your bank account, etc? I don't like having to trust dozens of CA and it's definitely not the best solution, but I don't see any alternative for this sort of thing. > > when you download openssh, does it come with bundled with a known hosts file? > > no, you go to the site and look at their public key. if they delegated their > public keys to a central authority they excert no control over, they don't > have > the power to shutdown their site when it becomes compromised to display bogus > public keys, or worse > > simlarly, i dont feed the cert bundle to sendmail, but instead feed it a > *single* cert that i'm vary wary of if it changes > > "ssl everywhere" is a stupid concept because of this. you should only ssl > select communications so that managing the certs is plausible > >> Additionally, you have to make users accept the cert manually the first >> time (checking it, of course). It may not be much of a fuss, but I >> don't see you actually fixing any security holes. >> >> -- >> Hugo Osvaldo Barrera >> >> -- Hugo Osvaldo Barrera
