You might be interested in the Lazarus add-on for various browsers (Firefox, Chrome, and Safari) which automatically saves changes made to forms and allows you to easily recover the contents with the click of the mouse. Very handy.
They probably are worried about bad guys using the payment system in an attempt to verify stolen credit cards by making seemingly-routine purchases that would not seem out of the ordinary and thus would not trip anti-fraud measures.
A small company I used to work for was abused by credit card thieves in this way, and dealing with the fraudulent charges and the resulting chargeback fees was the top non-salary cost for a few months (exceeding even the colocation costs). The problem existed because they allowed users to create either a free or paid account for the service and, if they selected the paid account, they could enter the card information on the sign-up page. Later, they changed it so users would need to create a free account (which required a captcha) and then upgrade it to a paid account in the account settings. Fraudulent charges dropped to essentially nil after that.
If the phone company requires only the invoice number and credit card data to pay a bill (rather than having you create an account, log in, and then pay the bill) then it's likely they're dealing with a similar problem.
The rock would have been at terminal velocity, which is typically less than 200 meters/sec (see here), since it has been slowed by the atmosphere. It's not landing in the lake at cosmic velocities (which would indeed be quite dramatic).
Using the standard car analogy, imaging dropping a car into the ice from a skyscraper conveniently located next to the ice. The car would not obliterate huge amounts of ice and vaporize large amounts of water -- it'd punch a somewhat-larger-than-car-sized hole in the ice.
Considering LavaBit is intended for the high-priority-needs user, I find it hard to suspect that this is a very large demographic.
Perhaps. I recall there being a rather substantial number of unhappy users who wanted access to their mail even if it could be snooped -- such users posted on various public fora, commented on articles, etc.
I wouldn't be surprised if many users used Lavabit simply because it was a reasonably priced (for the paid plans) IMAP/POP3/SMTP service with a strong privacy policy, didn't do data-mining, etc. Such users may well want to recover the contents of their mailboxes even if it means that they might get snooped on. If so, they can do so. If they don't feel comfortable with that, nobody's twisting their arms.:)
Then you are not the user that the archive download service is intended for.
Many users expressed a desire to download the contents of their mailbox even if it meant that the messages would be potentially snooped on, as they had important-but-not-private messages that they needed to recover. The archive download service is intended for those users, not those with high-security needs.
If one had enabled the secure storage functionality at Lavabit prior to the shutdown, the messages are inaccessible without the password. Naturally, with the password an adversary (say, the feds) could decrypt the messages (assuming they have a copy -- Ladar has stated in several public interviews that the feds did not make a copy of data on the servers).
Thus, one needs to balance the security of the messages stored with Lavabit with the desire to access old messages. Many users don't have any particular concern for privacy or security but have important messages in their mailbox that they would like to download (they might not have made local copies before the shutdown). This function is aimed at those people, not those that would prefer to keep messages encrypted even if they remain inaccessible to themselves.
Fortunately 5GHz penetrates walls very poorly -- I have a 6cm thick concrete interior wall (I'm in Switzerland, after all, they love concrete) that separates too rooms. The 5GHz signal in the room without an AP is so bad that my network card (a PCI-Express card for a desktop with three external antennas) essentially refuses to connect. 2.4GHz works fine. This is in an area with exactly zero 5GHz Wi-Fi users within range, a noise floor of about -95dBm, and no other sources of interference.
Channel bonding on 5GHz makes a lot of sense due to its extremely short range.
Ultimately, rotating certificates would make it a little harder to decrypt all traffic, wouldn't it? I'm not thinking in depth right now. But trust is a big issue then.
That's basically what Perfect Forward Secrecy (e.g. ephemerla Diffie-Hellman or Elliptic-Curve-Diffie-Hellman key exchange) does.
DH or ECDH key exchanges allow two parties to exchange a shared secret securely, but contain no way of verifying that the other party is who they claim to be -- there's no authentication. By signing the DH key exchange with a trusted certificate (i.e., one issued from a certificate authority) then the server can authenticate the key exchange.
This way, a long-term certificate can be used for identification/authentication by signing DH key exchanges that are used to exchange per-session ephemeral keys. Since the long-term certificate is only making signatures (rather than directly encrypting the session key), compromise of the long-term key does not reveal any information about the session keys.
Most servers and clients these days support PFS modes.
I'm pretty sure that you don't really know where the physical hardware using the intermediate IP addresses shown in the traceroute actually was. Reverse DNS tends to show who owns it, *not* which country it's in. And geoip services are doing well if they can identify the right country in Europe, let alone anything more accurate than that.
Even if you did see routing like that, and it really did go to the cities you claim, it still wouldn't be that odd - when routing is optimized at all it's optimized for cost, rather than distance. For long-haul the two tend to go together, but for relatively short distances in the well-connected first world they don't.
Not all network providers provide useful rDNS, but many (like Level3, Hurricane Electric, etc.) do -- their reverse DNS clearly indicates the location of that particular node (HE uses three letter abbreviations of city names, like "sjc" for "San Jose, California" or "ash" for "Ashburn, Virginia". Level3 includes the full name of the city.).
I've also seen odd routing paths. Usually they're transient and clear up at some later point.
Possibly, but the creation of the DNSSEC root keys was done completely in HSMs in a ceremony that was observed by many people from all over the world. No copy of the key was ever made outside an HSM.
The HSMs are stored in secure facilities and their disappearance would almost certainly be noticed.
Transferring the encrypted keys to another HSM is only possible if you get a quorum of people to approve such a transfer. Compromising sufficient people to do this would almost certainly be noticed, and many of the people are from outside the US.
The NSA could certainly steal (or legally compel the handover of) the HSM and try extracting the keys by taking apart the HSM, but the devices are tamper-resistant and would likely zeroise themselves prior to giving up their secrets. Even if they did succeed (the NSA might have some technique for doing so), it would be an expensive operation, technically challenging, and unlikely to be done in secret.
Is it possible? Sure. Is it likely? No, not really.
And to add insult to injury, the latest version of gmail will not let you attach a document to an email without first uploading it to drive. I am sure it works fine if you use an imap mail client, but the web-client is no good.
Sure you can.
Attachments that are too large (either exceeding the Gmail size limit or that of well-known recipient domains that Gmail knows about) will prompt you to upload the attachment to drive rather than trying to attach it directly.
That's actually a pretty handy, user-friendly thing to do.
True, and that's certainly a concern. The NSA could have chosen those parameters to weaken the algorithms or they could have chosen them to strengthen them much like they did with DES. Alternatively, the parameters could have been chose to optimize performance on certain systems, or perhaps even at random. It's not known why they chose what they did, so it makes sense to be somewhat skeptical. Still, the NSA recommends ECC for government use, so they seem to be reasonably confident about its security.
Additionally, ECC offers considerable performance improvements over discrete log algorithms. According to this site, adding perfect forward secrecy with ECC requires an additional overhead of 15-30% or so, depending on optimizations. Using discrete log-based Diffie Hellman key exchange there's an overhead of about 300%. That can be considerable when you're running services at the scale of, say, Google.
If you're particularly concerned about the security of ECC, and it's reasonable to be concerned, you could only use it where performance is important and extremely high security is not required.
Security is a strong PGP key kept safe and away from your PC, using a spare computer running DOS PGP version 2.6.Xg.
Using such an ancient version of PGP is probably a horrible idea, as there's been numerous security issues reported and fixed over the years by newer versions.
It'd probably be a better idea to use a modern copy of GnuPG: it's widely available, free and open source, implements the OpenPGP standard, and (while certainly not perfect) it lacks the known security issues that ancient versions of PGP have.
Forward secrecy is supported in Apache 2.2.x in the form of ephemeral Diffie Hellman key exchange ("DHE"). This works out-of-the-box on Debian and Ubuntu servers (I run a few Debian/Ubuntu servers, and have those options enabled) without needing to recompile anything.
Apache 2.4.x is require for use of elliptic curve ephemeral Diffie Hellman ("ECDHE"), which provides greater protection with shorter key lengths (e.g. a 256-bit EC key is equivalent to a 3072-bit discrete log key, but Apache 2.2.x uses a baked-in set of DH parameters that's only 1024-bits long). EC is also a lot faster than discrete log DH which is useful in certain environments.
That's irrelevant in this particular situation: the TPM is merely being to securely store a key and use that key -- entirely within the TPM -- to encrypt or decrypt data. The TPM could (and likely does) store other keys that aren't being used for this particular task, but that doesn't matter in this scenario. Although TPMs can be used for various purposes, in this case it'd be used like cryptographic smartcard or HSM.
Are you aware of any way of retrieving a private key stored on a TPM by any means other than physically taking it apart and probing the internal bits? If not, why not use the TPM as a secure key storage mechanism?
For landline phones in the US, the recipient does not pay unless they have a toll-free number (e.g. a 1-800 number). There's no connection fees for receiving a call.
Mobile phone numbers in the US are no different than landline phones for the calling party: there's no extra fee or anything for calling a mobile number. Calling a mobile costs precisely the same amount as calling any other phone number in that area code. The person with the mobile phone will be charged on a per-minute basis (unless they have an unlimited calling plan or it's during the "free nights and weekends" time that many plans offer) regardless of whether they are making or receiving a call.
This is different from, say, Europe, where mobile phones are assigned numbers in special mobile-only prefixes. The person calling a mobile phone pays a slight premium, while the person receiving a call on their mobile pays nothing.
You absolutely need to trap the packets in real time in order to actually break the VPN connection open so you can get at the actual payload (cleartext, post-decrypted) data within the stream. The initial cryptographic handshake has to be captured, in order for them to peel it open and get inside.
You can't do that days later, when all you have is an encrypted stream of bits.
I'm not sure I follow: how would capturing the cryptographic handshake help with "peeling open" the VPN connection? The handshake itself is secure: OpenVPN running in TLS mode (the most common mode) exchanges symmetric keys using an ephemeral Diffie-Hellman key exchange, with the key exchanged signed by the server's RSA key. Both client and server are authenticate to each other using certificates, so they can be sure that there's no man-in-the-middle. Unless one knows how to solve the Diffie-Hellman problem and one has a sensible configuration (i.e., sufficiently large DH parameters and RSA keys, good choice of symmetric cipher, etc.), capturing the cryptographic handshake doesn't really gain the attacker anything.
The government probably don't have the private keys themselves to the roots (they were generated on HSMs and likely can't be exported or copied) but may be able to compel a CA to issue false certificates.
This is a fairly easy thing to detect (particularly for sites that use certificate pinning, users with the Cert Patrol add-on for Firefox, etc.) -- while it might work for a bit, it probably won't work for very long. It's also a death sentence to CAs: once it gets out that they've issued fake certificates for government-sponsored man-in-the-middle attacks then those roots will almost certainly be removed by browser/system makers.
It's so their system will strip out referrals, thus increasing your privacy: the site you end up on won't know what search terms you used to get there.
I had a Facebook add pop up that said "Want an NSA Clearance?" (not a typo, the company messed up their grammar).
According to Purdue, words that start with consonants may be preceded with "an" if they have a "vowel sounds". They give the example of "an MSDS" and "an SPCC". Similarly, words that start with vowels but have consonant sounds use "a".
I'm no expert in grammar, but it seems possible that "an NSA clearance" may be correct.
But then again, we watched at the weekend as Canada destroyed the heart of one of its towns with an explosion caused by 'indestructable' and 'safe under every circumstance' oil-containing railway cars.
Who says the tank cars were "indestructible" or "safe under any circumstance"?
The tank cars involved in the Lac-Megantic incident were the DOT-111 type, which are the most common single type of railway tank car in North America. There have been concerns over the integrity of such tank cars for several decades. Various standards were changed a few years ago to improve the integrity of newly-made tank cars but existing tank cars are grandfathered in.
Pretty much nobody is claiming the tank cars are impervious to damage, and experts like the NTSB (US) and TSBC (CA) have expressed concerns over how easily the tanks can fail.
I have a Samsung B2710 (also available in the US from Amazon) that has a similar rating and is also impact-resistant. (Various tests have been carried out on this phone.) It's great for those who don't need a smartphone.
Mine has survived a few years of somewhat extreme travel, including meteorite search expeditions in the heat of the desert of Oman.
Slashdot Mirror
You might be interested in the Lazarus add-on for various browsers (Firefox, Chrome, and Safari) which automatically saves changes made to forms and allows you to easily recover the contents with the click of the mouse. Very handy.
They probably are worried about bad guys using the payment system in an attempt to verify stolen credit cards by making seemingly-routine purchases that would not seem out of the ordinary and thus would not trip anti-fraud measures.
A small company I used to work for was abused by credit card thieves in this way, and dealing with the fraudulent charges and the resulting chargeback fees was the top non-salary cost for a few months (exceeding even the colocation costs). The problem existed because they allowed users to create either a free or paid account for the service and, if they selected the paid account, they could enter the card information on the sign-up page. Later, they changed it so users would need to create a free account (which required a captcha) and then upgrade it to a paid account in the account settings. Fraudulent charges dropped to essentially nil after that.
If the phone company requires only the invoice number and credit card data to pay a bill (rather than having you create an account, log in, and then pay the bill) then it's likely they're dealing with a similar problem.
Apologies: the link didn't get included in my "see here" bit. The actual link is at http://www.amsmeteors.org/fireballs/faqf/#12
The rock would have been at terminal velocity, which is typically less than 200 meters/sec (see here), since it has been slowed by the atmosphere. It's not landing in the lake at cosmic velocities (which would indeed be quite dramatic).
Using the standard car analogy, imaging dropping a car into the ice from a skyscraper conveniently located next to the ice. The car would not obliterate huge amounts of ice and vaporize large amounts of water -- it'd punch a somewhat-larger-than-car-sized hole in the ice.
Considering LavaBit is intended for the high-priority-needs user, I find it hard to suspect that this is a very large demographic.
Perhaps. I recall there being a rather substantial number of unhappy users who wanted access to their mail even if it could be snooped -- such users posted on various public fora, commented on articles, etc.
I wouldn't be surprised if many users used Lavabit simply because it was a reasonably priced (for the paid plans) IMAP/POP3/SMTP service with a strong privacy policy, didn't do data-mining, etc. Such users may well want to recover the contents of their mailboxes even if it means that they might get snooped on. If so, they can do so. If they don't feel comfortable with that, nobody's twisting their arms. :)
i consider my lavabit mail a lost cause
Then you are not the user that the archive download service is intended for.
Many users expressed a desire to download the contents of their mailbox even if it meant that the messages would be potentially snooped on, as they had important-but-not-private messages that they needed to recover. The archive download service is intended for those users, not those with high-security needs.
If one had enabled the secure storage functionality at Lavabit prior to the shutdown, the messages are inaccessible without the password. Naturally, with the password an adversary (say, the feds) could decrypt the messages (assuming they have a copy -- Ladar has stated in several public interviews that the feds did not make a copy of data on the servers).
Thus, one needs to balance the security of the messages stored with Lavabit with the desire to access old messages. Many users don't have any particular concern for privacy or security but have important messages in their mailbox that they would like to download (they might not have made local copies before the shutdown). This function is aimed at those people, not those that would prefer to keep messages encrypted even if they remain inaccessible to themselves.
Fortunately 5GHz penetrates walls very poorly -- I have a 6cm thick concrete interior wall (I'm in Switzerland, after all, they love concrete) that separates too rooms. The 5GHz signal in the room without an AP is so bad that my network card (a PCI-Express card for a desktop with three external antennas) essentially refuses to connect. 2.4GHz works fine. This is in an area with exactly zero 5GHz Wi-Fi users within range, a noise floor of about -95dBm, and no other sources of interference.
Channel bonding on 5GHz makes a lot of sense due to its extremely short range.
Ultimately, rotating certificates would make it a little harder to decrypt all traffic, wouldn't it? I'm not thinking in depth right now. But trust is a big issue then.
That's basically what Perfect Forward Secrecy (e.g. ephemerla Diffie-Hellman or Elliptic-Curve-Diffie-Hellman key exchange) does.
DH or ECDH key exchanges allow two parties to exchange a shared secret securely, but contain no way of verifying that the other party is who they claim to be -- there's no authentication. By signing the DH key exchange with a trusted certificate (i.e., one issued from a certificate authority) then the server can authenticate the key exchange.
This way, a long-term certificate can be used for identification/authentication by signing DH key exchanges that are used to exchange per-session ephemeral keys. Since the long-term certificate is only making signatures (rather than directly encrypting the session key), compromise of the long-term key does not reveal any information about the session keys.
Most servers and clients these days support PFS modes.
I'm pretty sure that you don't really know where the physical hardware using the intermediate IP addresses shown in the traceroute actually was. Reverse DNS tends to show who owns it, *not* which country it's in. And geoip services are doing well if they can identify the right country in Europe, let alone anything more accurate than that.
Even if you did see routing like that, and it really did go to the cities you claim, it still wouldn't be that odd - when routing is optimized at all it's optimized for cost, rather than distance. For long-haul the two tend to go together, but for relatively short distances in the well-connected first world they don't.
Not all network providers provide useful rDNS, but many (like Level3, Hurricane Electric, etc.) do -- their reverse DNS clearly indicates the location of that particular node (HE uses three letter abbreviations of city names, like "sjc" for "San Jose, California" or "ash" for "Ashburn, Virginia". Level3 includes the full name of the city.).
I've also seen odd routing paths. Usually they're transient and clear up at some later point.
Possibly, but the creation of the DNSSEC root keys was done completely in HSMs in a ceremony that was observed by many people from all over the world. No copy of the key was ever made outside an HSM.
The HSMs are stored in secure facilities and their disappearance would almost certainly be noticed.
Transferring the encrypted keys to another HSM is only possible if you get a quorum of people to approve such a transfer. Compromising sufficient people to do this would almost certainly be noticed, and many of the people are from outside the US.
The NSA could certainly steal (or legally compel the handover of) the HSM and try extracting the keys by taking apart the HSM, but the devices are tamper-resistant and would likely zeroise themselves prior to giving up their secrets. Even if they did succeed (the NSA might have some technique for doing so), it would be an expensive operation, technically challenging, and unlikely to be done in secret.
Is it possible? Sure. Is it likely? No, not really.
And to add insult to injury, the latest version of gmail will not let you attach a document to an email without first uploading it to drive. I am sure it works fine if you use an imap mail client, but the web-client is no good.
Sure you can.
Attachments that are too large (either exceeding the Gmail size limit or that of well-known recipient domains that Gmail knows about) will prompt you to upload the attachment to drive rather than trying to attach it directly.
That's actually a pretty handy, user-friendly thing to do.
It's wise to put your company's future in the hands of people overseas.
Nothing could go wrong there.
Because manufacturing facilities in $YOUR_COUNTRY_OF_RESIDENCE don't ever experience fires or other production-halting mishaps?
True, and that's certainly a concern. The NSA could have chosen those parameters to weaken the algorithms or they could have chosen them to strengthen them much like they did with DES. Alternatively, the parameters could have been chose to optimize performance on certain systems, or perhaps even at random. It's not known why they chose what they did, so it makes sense to be somewhat skeptical. Still, the NSA recommends ECC for government use, so they seem to be reasonably confident about its security.
Additionally, ECC offers considerable performance improvements over discrete log algorithms. According to this site, adding perfect forward secrecy with ECC requires an additional overhead of 15-30% or so, depending on optimizations. Using discrete log-based Diffie Hellman key exchange there's an overhead of about 300%. That can be considerable when you're running services at the scale of, say, Google.
If you're particularly concerned about the security of ECC, and it's reasonable to be concerned, you could only use it where performance is important and extremely high security is not required.
Security is a strong PGP key kept safe and away from your PC, using a spare computer running DOS PGP version 2.6.Xg.
Using such an ancient version of PGP is probably a horrible idea, as there's been numerous security issues reported and fixed over the years by newer versions.
It'd probably be a better idea to use a modern copy of GnuPG: it's widely available, free and open source, implements the OpenPGP standard, and (while certainly not perfect) it lacks the known security issues that ancient versions of PGP have.
Forward secrecy is supported in Apache 2.2.x in the form of ephemeral Diffie Hellman key exchange ("DHE"). This works out-of-the-box on Debian and Ubuntu servers (I run a few Debian/Ubuntu servers, and have those options enabled) without needing to recompile anything.
Apache 2.4.x is require for use of elliptic curve ephemeral Diffie Hellman ("ECDHE"), which provides greater protection with shorter key lengths (e.g. a 256-bit EC key is equivalent to a 3072-bit discrete log key, but Apache 2.2.x uses a baked-in set of DH parameters that's only 1024-bits long). EC is also a lot faster than discrete log DH which is useful in certain environments.
That's irrelevant in this particular situation: the TPM is merely being to securely store a key and use that key -- entirely within the TPM -- to encrypt or decrypt data. The TPM could (and likely does) store other keys that aren't being used for this particular task, but that doesn't matter in this scenario. Although TPMs can be used for various purposes, in this case it'd be used like cryptographic smartcard or HSM.
Are you aware of any way of retrieving a private key stored on a TPM by any means other than physically taking it apart and probing the internal bits? If not, why not use the TPM as a secure key storage mechanism?
For landline phones in the US, the recipient does not pay unless they have a toll-free number (e.g. a 1-800 number). There's no connection fees for receiving a call.
Mobile phone numbers in the US are no different than landline phones for the calling party: there's no extra fee or anything for calling a mobile number. Calling a mobile costs precisely the same amount as calling any other phone number in that area code. The person with the mobile phone will be charged on a per-minute basis (unless they have an unlimited calling plan or it's during the "free nights and weekends" time that many plans offer) regardless of whether they are making or receiving a call.
This is different from, say, Europe, where mobile phones are assigned numbers in special mobile-only prefixes. The person calling a mobile phone pays a slight premium, while the person receiving a call on their mobile pays nothing.
You absolutely need to trap the packets in real time in order to actually break the VPN connection open so you can get at the actual payload (cleartext, post-decrypted) data within the stream. The initial cryptographic handshake has to be captured, in order for them to peel it open and get inside.
You can't do that days later, when all you have is an encrypted stream of bits.
I'm not sure I follow: how would capturing the cryptographic handshake help with "peeling open" the VPN connection? The handshake itself is secure: OpenVPN running in TLS mode (the most common mode) exchanges symmetric keys using an ephemeral Diffie-Hellman key exchange, with the key exchanged signed by the server's RSA key. Both client and server are authenticate to each other using certificates, so they can be sure that there's no man-in-the-middle. Unless one knows how to solve the Diffie-Hellman problem and one has a sensible configuration (i.e., sufficiently large DH parameters and RSA keys, good choice of symmetric cipher, etc.), capturing the cryptographic handshake doesn't really gain the attacker anything.
The government probably don't have the private keys themselves to the roots (they were generated on HSMs and likely can't be exported or copied) but may be able to compel a CA to issue false certificates.
This is a fairly easy thing to detect (particularly for sites that use certificate pinning, users with the Cert Patrol add-on for Firefox, etc.) -- while it might work for a bit, it probably won't work for very long. It's also a death sentence to CAs: once it gets out that they've issued fake certificates for government-sponsored man-in-the-middle attacks then those roots will almost certainly be removed by browser/system makers.
Well, it was reported by The New York Times, The Wall Street Journal, The Washington Post, CNN, CBS, and others (ABC, Fox News, NPR, etc.).
As far as I can tell, all the major US news companies reported on the closings.
It's so their system will strip out referrals, thus increasing your privacy: the site you end up on won't know what search terms you used to get there.
I had a Facebook add pop up that said "Want an NSA Clearance?" (not a typo, the company messed up their grammar).
According to Purdue, words that start with consonants may be preceded with "an" if they have a "vowel sounds". They give the example of "an MSDS" and "an SPCC". Similarly, words that start with vowels but have consonant sounds use "a".
I'm no expert in grammar, but it seems possible that "an NSA clearance" may be correct.
Any experts want to chime in?
But then again, we watched at the weekend as Canada destroyed the heart of one of its towns with an explosion caused by 'indestructable' and 'safe under every circumstance' oil-containing railway cars.
Who says the tank cars were "indestructible" or "safe under any circumstance"?
The tank cars involved in the Lac-Megantic incident were the DOT-111 type, which are the most common single type of railway tank car in North America. There have been concerns over the integrity of such tank cars for several decades. Various standards were changed a few years ago to improve the integrity of newly-made tank cars but existing tank cars are grandfathered in.
Pretty much nobody is claiming the tank cars are impervious to damage, and experts like the NTSB (US) and TSBC (CA) have expressed concerns over how easily the tanks can fail.
I have a Samsung B2710 (also available in the US from Amazon) that has a similar rating and is also impact-resistant. (Various tests have been carried out on this phone.) It's great for those who don't need a smartphone.
Mine has survived a few years of somewhat extreme travel, including meteorite search expeditions in the heat of the desert of Oman.