nationwide interception of Facebook & webmail login credentials in Tunisia

Mark Lomas ukcrypto at
Wed Mar 23 21:05:21 GMT 2011

This story reminds me of something I said in January (and in about 2000):


On 26 January 2011 09:18, Mark Lomas <ukcrypto at> wrote:

> Some years ago (probably in 2000) I persuaded a major bank to remove the
> majority of CA certificates from the key store of the browser they had
> deployed.
> The IT department regarded the change as a nuisance, but the Legal
> department understood the problem as soon as I showed them the list of CAs.
> May I conduct an informal survey? Who on this mailing list has not removed
> any of the CA certificates that were pre-installed by whoever supplied your
> browser?
>         Mark
> On 25 January 2011 20:24, Ian Batten <igb at> wrote:
>> On 25 Jan 2011, at 16:18, Passive PROFITS wrote:
>> > That would not deal with the falsifying of certificates.  Assuming the
>> code-base of this is not intentional corrupt, the addition of an extension
>> such as certpatrol is also required (a firefox extension), to notify one
>> when the SSL cert swap by the government/ISP (using the browser accepted as
>> 'true' passported C.A.(s) under their control) has taken place (a MiTM is in
>> progress notification function).  The other known way would be manual/local
>> (each time) inspection of the cert fingerprint(s).  e.g. you note Facebook's
>> fingerprint then check each time it's got the same 'print.  Then (once under
>> notice the hack is under progress) you could retreat, or start playing your
>> own pre-planned counter-measures ... depending on the peril of the
>> situation, tactics, etc, call the government, depending on the nature of
>> your business, etc.
>> There's been some recent, if un-startling, discussion of this:
>> I suspect that once you have more than a handful of CAs, it's for
>> practical purposes impossible to get any meaningful assurance that they are
>> all legitimate.   If CAs delegate their authority, it's difficult to even
>> know that certificates whose chain of trust goes back to a CA you trust was
>> actually issued by that CA.  And for as long as any CA can issue a
>> certificate in any name, any domain can be subverted by any one of the CAs.
>> Which means that certificates are as weak as the weakest CA you trust,
>> unless that CA in turn trusts a yet weaker CA.
>> I've not looked at this in detail (perhaps I should) but I think it's
>> possible in most browsers to trust _no_ CAs and yet trust individual
>> certificates, which might have the required semantics: when a certificate is
>> encountered, you check it (by whatever out of band mechanism you deem
>> appropriate) and then add it to your certificate store, but you do not add
>> its certifying keys.
>> ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ukcrypto mailing list