On Wed, Feb 23, 2011 at 9:20 PM, Hugo Osvaldo Barrera <h...@osvaldobarrera.com.ar> wrote: > 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.
i hope that you realize that the loop applies to the initial distribution of the bundle aswell and that the difference after that is one is centralized (bigger target) and the other one isn't you're going to get their crl from them, right? like the millions of other people that trust them should? > >>>> >>>> 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. B 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? B Check your bank account, etc? B 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. my bank account and other items would never account for the plethora of bundled certs, nor with the inability of a client to associate cacerts with specific hosts. the latter is why your argument is flawed, and it has nothing to do with self-singing a cert pool should have varying degrees of trust and reach. if firefox doesn't do this, the problem is firefox and not the server's cert distribution model > >> >> 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). B 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
