New Research Suggests That Governments May Fake SSL Certificates
March 24th, 2010 New Research Suggests That Governments May Fake SSL Certificates Technical Analysis by Seth Schoen http://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl Today two computer security researchers, Christopher Soghoian and Sid Stamm, released a draft of a forthcoming research paper in which theypresent evidence that certificate authorities (CAs) may be cooperating with government agencies to help them spy undetected on secure encrypted communications. (EFF sometimes advises Soghoian on responsible disclosure issues, including for this paper.) More details and reporting are available at Wired today. The draft paper includes marketing materials from Packet Forensics, an Arizona company, which suggests that government users have the ability to import a copy of any legitimate keys they obtain (potentially by court order) into Packet Forensics products in order to impersonate sites and trick users into a false sense of security afforded by web, e-mail, or VoIP encryption. This would allow those governments to routinely bypass encryption without breaking it.. Soghoian and Stamm also observe that browsers trust huge numbers of CAs — and all of those organizations are trusted completely, so that the validity of any entity they approve is accepted without question. Every organization on a browser's trusted list has the power to certify sites all around the world. Existing browsers do not consider whether a certificate was signed by a different CA than before; a laptop that has seen Gmail's site certified by a subsidiary of U.S.-based VeriSign thousands of times would raise no alarm if Gmail suddenly appeared to present a different key apparently certified by an authority in Poland, the United Arab Emirates, Turkey, or Brazil. Yet such a change would be an indication that the user's encrypted HTTP traffic was being intercepted. Paper: http://files.cloudprivacy.net/ssl-mitm.pdf Respectfully, Dave Kleiman - http://www.ComputerForensicExaminer.com - http://www.DigitalForensicExpert.com 4371 Northlake Blvd #314 Palm Beach Gardens, FL 33410 561.310.8801
RE: Solving password problems one at a time, Re: The password-reset paradox
On February 21, 2009 14:34, Ed Gerck wrote: In a business, one must write down the passwords and one must have a duplicate copy of it, with further backup, where management can access it. This is SOP. This is done not just in case the proverbial truck hits the employee, or fire strikes the building, or for the disgruntled cases, but because people do forget and a company cannot be at the same time responsible to the shareholders for its daily operations and not be responsible for the passwords that pretty much define how those daily operations are run. The idea that people should not write their passwords is thus silly from the security viewpoint of assuring availability and also for another reason. Users cannot be trusted to follow instructions. So, if one's security depends on their users following instructions, then something is wrong from the start. Most organizations I interact with have an SOP that nobody should ever know another's password. The only passwords that are safe stored are those for encryption or the top level admin. You take on a degree of legal responsibility if you have the ability to logon as another user. Since the admin can easily change a user's password, what would be the necessity for this risk? All password changes should be audited. Respectfully, Dave Kleiman - http://www.ComputerForensicExaminer.com 4371 Northlake Blvd #314 Palm Beach Gardens, FL 33410 561.310.8801 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: [heise online UK] Secure deletion: a single overwrite will do it
On Mon, 19 Jan 2009, Stefan Kelm wrote: ...it has to be overwritten completely, sector by sector. Although this takes time, it costs nothing: the dd command in any Linux distribution will do the job perfectly. Note quite perfectly, and not nearly as fast as the built-in option (see below). On Mon, 20 Jan 2009, Jason wrote: I agree in general, although you still have to watch out for reserve tracks (search on this page).All hard disks have reserved sectors, which are used automatically by the drive logic if there is a defect in the media.: Yes the main areas you are referring to are known as the P-List (Primary Defects List – manufacture defect info that does not change) G-List (Grown Defects Lists – sector relocation table). You can only access the P-List with special commands and tools. However, you can wipe the G-List are if you do it outside of an OS (or a tool that can access the system area), since the OS knows nothing of these sectors. The easiest (possible the best because of speed) way to accomplish this in modern ATA hard drives (2001 forward) is with the built-in Secure Erase program. Conveniently placed there for us by Recording Research (CMRR) headed by Gordon Hughes, Associate Director of CMRR, USSD on the Secure Erase Initiative. At the ANSI T-13 Committee meeting in 2004, Gordon described the differences between block erase as described in government document DoD2550 and Secure Erase. Unlike block level erase Secure Erase also overwrites reassigned blocks and can be up to eight times faster (per CMRR tests). In addition the enhanced SE command qualifies for Federal Government secret data classification erasure. You can download a DOS-based utility HDDerase that securely erases all data on ATA hard disk drives via the internal secure erase command. http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml And yes, I am the same Dave Kleiman from the paper. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Can you keep a secret? This encrypted drive can...
-Original Message- From: Saqib Ali [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 08:16 Hello Alexander, My guess is that slow compilation is a result of access time misconfiguration: if a filesystem has access time enabled, then each time a file is read, the file system updates access time on disk. A solution is to set noatime option on the filesystem used for compilation. This is a good info. Do you how this can be done on windows? It is on page 43 and 44 of a class I did at the last CyberCrime Summit: http://davekleiman.com/Files/HTCIACyberCrimeSummit_For_CD.zip Additionally, I talk about using Log Parser to retrieve information from the filesystem and log files without causing access updates - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Are laptop search seizures increasing use of disk crypto?
-Original Message- From: Udhay Shankar N Sent: Thursday, October 26, 2006 01:00 Like the subject says - I'm curious whether the current regime of inspection and forensic analysis of laptops, primarily in the US, has affected corporate policies regarding disk crypto. Is there anybody studying this? Any resources available online? Funny you should mention that, just saw this today: At U.S. Borders, Laptops Have No Right to Privacy http://travel2.nytimes.com/2006/10/24/business/24road.html We have be spending an increasing amount of time working with vendors of both forensic tools and disc encryption technology, trying to find tips, tricks, and techniques that can be used when warranted. Respectfully, Dave Kleiman - http://www.davekleiman.com/about.php - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Verisign CRL single point of failure
I don't think you understood my question. Why is crl.verisign.com getting overloaded *now.* What does the expiration of one of their CA certificates have to do with it? Once you see that a cert has expired, there's no need whatsoever to go look at the CRL. The point of a CRL is to revoke certificates prior to their expiration. You are correct I did miss your point in haste. I cannot answer that, but I can tell you that disabling the function or uninstalling NAV that has CRL function, fixes the problem immediately. And if you watch your firewall as the clients open a file that requests a virus scan they all try to hit crl.verisign.com. This has been happening since the 7th when that cert expired. DK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
