Mozilla has updated its Certificate Authority (CA) Certificate Policy to lessen the risk of hackers getting their hands on subordinate CA certificates.
Subordinate CA certificates are granted the same power as the CA, and they can be used to issue valid SSL certificates.
Until now, subordinate CA certificates have not been subjected to the same scrutiny and controls as root CA certificates.
The policy is being changed to reflect Mozilla's "belief that each root is ultimately accountable for every certificate it signs, directly or through its subordinates."
Subordinate CA certificates issued after May 15, 2013 must comply with Mozilla's new policy; existing certificates have until May 15, 2014 to be updated to comply with the policy
Wednesday 27 February 2013
Wednesday 20 February 2013
DNSSEC Adoption Growing in Government, But Unpopular with eCommerce and Finance
Although DNSSEC (DNS Security Extensions) technology helps prevent spoofing of websites, none of the top e-commerce companies or banking and financial services companies have deployed it fully.
In contrast, two-thirds of US government agencies are using DNSSEC, although some of the agencies are signing their domains incorrectly.
-http://www.theregister.co.uk/2013/02/18/dnssec/
I imagine that in the US in 1963 there were similar stories about the unpopularity of a change required to make delivery of physical messages more reliable. It was called the Zone Improvement Plan - and these days we routinely put ZIP codes on snail mail addresses without grumbling. Need to get over that hump with DNSSEC - and then use the freed-up energy to push BGP and SSL Certificate Authority security improvements up the next hill.
Having implemented DNSSEC for a few domains, I found out first hand that it is very easy to "mess up" and render a domain non resolvable. Even some notable .gov sites (like for example fbi.gov) fell victim to badly configured DNSSEC in the past. On the other hand, attacks that involve DNS spoofing are rare and not considered a sufficient risk compared to the risk of downtime due to badly configured DNSSEC signatures.
This may however change as more commercial DNS providers will offer DNSSEC as a service and as popular DNS servers like BIND make configuring DNSSEC easier.
In contrast, two-thirds of US government agencies are using DNSSEC, although some of the agencies are signing their domains incorrectly.
-http://www.theregister.co.uk/2013/02/18/dnssec/
I imagine that in the US in 1963 there were similar stories about the unpopularity of a change required to make delivery of physical messages more reliable. It was called the Zone Improvement Plan - and these days we routinely put ZIP codes on snail mail addresses without grumbling. Need to get over that hump with DNSSEC - and then use the freed-up energy to push BGP and SSL Certificate Authority security improvements up the next hill.
Having implemented DNSSEC for a few domains, I found out first hand that it is very easy to "mess up" and render a domain non resolvable. Even some notable .gov sites (like for example fbi.gov) fell victim to badly configured DNSSEC in the past. On the other hand, attacks that involve DNS spoofing are rare and not considered a sufficient risk compared to the risk of downtime due to badly configured DNSSEC signatures.
This may however change as more commercial DNS providers will offer DNSSEC as a service and as popular DNS servers like BIND make configuring DNSSEC easier.
Tuesday 5 February 2013
Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
Nadhem AlFardan and Kenny Paterson of the Information Security Group at Royal Holloway, University of London, announced a new TLS/DTLS attack called Lucky Thirteen. The attack allows a man-in-the-middle attacker to recover plaintext from a TLS/DTLS connection when CBC-mode (cipher-block chaining) encryption is used.
http://www.isg.rhul.ac.uk/tls/TLStiming.pdf
Subscribe to:
Posts (Atom)