True ephemeral keys will be an issue, however this does present an avenue for man-in-the-middle compromises. (and has been brought up in various security circles.) To date, only one customer has ever asked why select sessions weren't being processed -- this was a major US University with SSLv1 enabled that was allowing 56bit keys. Those sessions don't use the server key, so we can't decode them. (given a few days, we could recover a single session key, being 56bit DES.)
Also, computers are very bad at doing anything truly random. While I'm not going to attack any PRNG's any time soon, I'm pretty sure the NSA already does (and likely had a finger or two in a few algorithms.)
Doesn't apply. With the server key, you can do the exact same math as the server to generate the exact same master secret and decode the entire stream.
(I've been building systems to do this for over a decade. Sure, it's easier if you happen to be the load-balancer -- i.e. "server" -- in the equation, but out-of-band monitoring of SSL is Very. Real.)
Or more likely (as in they-are-already-doing-this)... record TB's of encrypted traffic until they can seize the server (and thus the certificate). Once they have the server certificate, they can decrypt every session that has ever been encrypted with it.
Exactly. It's just more theater. 99% of those "cheap" ssl certificates are not validated AT ALL. People are blindly putting trust into a system that has none.
And on top of this, SSL is an exceptionally expensive computation. It takes rather expensive dedicated hardware to handle at any meaningful rate. (go play with the opensssl speed tool to see for yourself)
I've never seen an Internet based VoIP provider using TFTP. TFTP is horrible across the internet. Every modern SIP phone I've encountered (with the exception of Cisco, who still want everything to run Skinny) can (and does) use HTTP. In fact, the Avaya phones I just setup almost insist on SSL/TLS. (they do eventually fall back to plain HTTP. And they want to use TCP/TLS to talk to the PBX.)
"Into their network" as in "from the customer in the first place". An ISP's interconnect is a poor place to do such checks. They should be done as close as possible to the customer. In the DOCSIS world, dhcp-snooping is enough. In a DSL PPPoE world, them sort of thing should be done at the BRAS.
The correct answer is that many ISPs are both lazy and stupid, and simply will not take the time and effort to setup their network(s) correctly.
Cisco does not use TFTP to "boot a lot of their crap." TFTP is the recovery mechanism -- and historically, the default means of transferring firmware and configs (in and out) -- they boot from their local storage. Unless specifically, and explicitly configured to do so, IOS devices are not tftp-servers. (it's typically only enabled as part of call-manager setup as that's how phones get firmware, configs, ringtone, etc.)
Opera has been a Chrome ripoff for a long time now. Real Opera(tm) is INFINITELY better than anything else... the same set of tabs open in Opera vs. Chrome (and New Opera): 200M vs. 1.2G -- New Opera makes no meaningful improvements.
You assume the military is telling the truth about their weapons stocks. (that'd be a bad bet.) Even though each warhead is a few hundred KT, we put many more than ONE on a missile.
(and a neutron bomb doesn't have to be very "big". that said one might think NK's dismal nuke tests could be neutron bomb tests.)
(note: for all the "white box" switches on the market, Broadcom goes out of their way to not give you the actual SDK. Instead their "open" bullshit is an already compiled library.)
They all use standard Broadcom trash. (everybody does) The "reference code" (aka: SDK) isn't an OS. It's a library, and if you build it, a diagnostic shell. Any OS, UI, configuration language, etc. are up to the vendor.
Depending on how old it is, they DID rebuilt 8.2.5 to fix the latest round of stupid. One email or phone call will get you the necessary image. (or, ya'know, use the internet like everyone else. It's faster.)
Nope. Companies are creating things LEO's cannot defeat. (and in the case of iPhones, something even Apple cannot defeat. Unless they start recording the UIDs of every device.)
No he's not. The iPhone does not contain a HARD DRIVE; it has a flash memory chip. The entire contents of which are encrypted. Removing that chip (which is not easy) would yield nothing but a bunch of random garbage. After 1.2million years of attempting keys, you might gain access to the filesystem, only to find EVERY file of value encrypted yet again (with various keys).
The thing that needs to be backed up -- the UID and key built from it -- cannot be accessed.
The only possible grounds for complaint is that it's shipped with the base kernel (linux-image-4.4.0-7-generic) I've not unpacked the source package to see if they ship it with zfs already shoe-spooned into the tree. (but, there is an update-zfs.sh script in the debian specific parts) In fact, most of the modules are "GPL", not "GPL v2"; and yes, the zfs stuff are the only non-GPL modules in the package.
HOWEVER: Adding a file to an archive of your own making (i.e. a dot.deb, dot.rpm, dot.pkg, dot.zip, dot.tgz,...) has ZERO entanglement with the GPL. If that were true, ISO's and disk images would be "illegal".
They learned a hard lesson on that one... an exploit was found in the boot loader that cannot be updated, thus, every iDevice of that generation could be hacked. It was fixed in later models.
Because their security wasn't design by a 3yo in crayon.
The attempts count is tracked by the Secure Enclave (or crypto engine -- Apple isn't clear on that part.) It's information is itself encrypted, and not directly accessible by anything but the SE. (it even scrambles it's part of main RAM) There is no way to "backup" the things the SE is tracking, or the key it's going to destroy. (and it's going to send low-level commands to the flash controller to erase every cell in which the key has ever been stored.)
(a) It's evidence. They cannot "drill into it". (b) Apple designed to the processor to resist such attempts. (it's actually codified in FIPS-140 standards) It's hardened against x-ray imaging.
In theory, by providing a different firmware for the Secure Enclave (isolated processor) that ignores the "erase me" bit, and does not introduce any per-attempt delays. And then provide a second "app" to allow electronic entry of passcodes (via USB, bluetooth, etc.) They can certainly write that, but getting it into the sterile environment of evidence (run entirely from RAM, touch nothing else) may not be possible.
Because what they need is built into the main processor (specifically the crypto logic) with ZERO interfaces for retrieving it. The flash chip is AES-256 encrypted. It will take, literally, an eternity to break it. (and no, one cannot recover the key via x-ray imaging.)
Slashdot Mirror
True ephemeral keys will be an issue, however this does present an avenue for man-in-the-middle compromises. (and has been brought up in various security circles.) To date, only one customer has ever asked why select sessions weren't being processed -- this was a major US University with SSLv1 enabled that was allowing 56bit keys. Those sessions don't use the server key, so we can't decode them. (given a few days, we could recover a single session key, being 56bit DES.)
Also, computers are very bad at doing anything truly random. While I'm not going to attack any PRNG's any time soon, I'm pretty sure the NSA already does (and likely had a finger or two in a few algorithms.)
Doesn't apply. With the server key, you can do the exact same math as the server to generate the exact same master secret and decode the entire stream.
(I've been building systems to do this for over a decade. Sure, it's easier if you happen to be the load-balancer -- i.e. "server" -- in the equation, but out-of-band monitoring of SSL is Very. Real.)
Or more likely (as in they-are-already-doing-this)... record TB's of encrypted traffic until they can seize the server (and thus the certificate). Once they have the server certificate, they can decrypt every session that has ever been encrypted with it.
Exactly. It's just more theater. 99% of those "cheap" ssl certificates are not validated AT ALL. People are blindly putting trust into a system that has none.
And on top of this, SSL is an exceptionally expensive computation. It takes rather expensive dedicated hardware to handle at any meaningful rate. (go play with the opensssl speed tool to see for yourself)
I've never seen an Internet based VoIP provider using TFTP. TFTP is horrible across the internet. Every modern SIP phone I've encountered (with the exception of Cisco, who still want everything to run Skinny) can (and does) use HTTP. In fact, the Avaya phones I just setup almost insist on SSL/TLS. (they do eventually fall back to plain HTTP. And they want to use TCP/TLS to talk to the PBX.)
"Into their network" as in "from the customer in the first place". An ISP's interconnect is a poor place to do such checks. They should be done as close as possible to the customer. In the DOCSIS world, dhcp-snooping is enough. In a DSL PPPoE world, them sort of thing should be done at the BRAS.
The correct answer is that many ISPs are both lazy and stupid, and simply will not take the time and effort to setup their network(s) correctly.
Cisco does not use TFTP to "boot a lot of their crap." TFTP is the recovery mechanism -- and historically, the default means of transferring firmware and configs (in and out) -- they boot from their local storage. Unless specifically, and explicitly configured to do so, IOS devices are not tftp-servers. (it's typically only enabled as part of call-manager setup as that's how phones get firmware, configs, ringtone, etc.)
To be fair, he blow up his ship (that he had to steal in the first place) and that Klingon junker was all that was available.
Opera has been a Chrome ripoff for a long time now. Real Opera(tm) is INFINITELY better than anything else... the same set of tabs open in Opera vs. Chrome (and New Opera): 200M vs. 1.2G -- New Opera makes no meaningful improvements.
You assume the military is telling the truth about their weapons stocks. (that'd be a bad bet.) Even though each warhead is a few hundred KT, we put many more than ONE on a missile.
(and a neutron bomb doesn't have to be very "big". that said one might think NK's dismal nuke tests could be neutron bomb tests.)
Station wagon with a lead pipe full of radioactive trash. Maybe not to the US mainland, but to US interests around the world, sure.
Weeks? If they lob a nuke, it'll be over in HOURS. And it won't necessarily even involve the US.
By their lack-luster nuclear tests. They have the nuke equiv of a firecracker. Kill people and make a hell of a mess, sure; vaporize a city, no.
(note: for all the "white box" switches on the market, Broadcom goes out of their way to not give you the actual SDK. Instead their "open" bullshit is an already compiled library.)
They all use standard Broadcom trash. (everybody does) The "reference code" (aka: SDK) isn't an OS. It's a library, and if you build it, a diagnostic shell. Any OS, UI, configuration language, etc. are up to the vendor.
Depending on how old it is, they DID rebuilt 8.2.5 to fix the latest round of stupid. One email or phone call will get you the necessary image. (or, ya'know, use the internet like everyone else. It's faster.)
Nope. Companies are creating things LEO's cannot defeat. (and in the case of iPhones, something even Apple cannot defeat. Unless they start recording the UIDs of every device.)
No he's not. The iPhone does not contain a HARD DRIVE; it has a flash memory chip. The entire contents of which are encrypted. Removing that chip (which is not easy) would yield nothing but a bunch of random garbage. After 1.2million years of attempting keys, you might gain access to the filesystem, only to find EVERY file of value encrypted yet again (with various keys).
The thing that needs to be backed up -- the UID and key built from it -- cannot be accessed.
Translation: *whaaa*We don't like ZFS*whaaa*
The only possible grounds for complaint is that it's shipped with the base kernel (linux-image-4.4.0-7-generic) I've not unpacked the source package to see if they ship it with zfs already shoe-spooned into the tree. (but, there is an update-zfs.sh script in the debian specific parts) In fact, most of the modules are "GPL", not "GPL v2"; and yes, the zfs stuff are the only non-GPL modules in the package.
HOWEVER: Adding a file to an archive of your own making (i.e. a dot.deb, dot.rpm, dot.pkg, dot.zip, dot.tgz, ...) has ZERO entanglement with the GPL. If that were true, ISO's and disk images would be "illegal".
They learned a hard lesson on that one... an exploit was found in the boot loader that cannot be updated, thus, every iDevice of that generation could be hacked. It was fixed in later models.
And only if it's been unlocked since the last reboot. (it's been powered down since then, so there's no way to touch the data on it.)
Because their security wasn't design by a 3yo in crayon.
The attempts count is tracked by the Secure Enclave (or crypto engine -- Apple isn't clear on that part.) It's information is itself encrypted, and not directly accessible by anything but the SE. (it even scrambles it's part of main RAM) There is no way to "backup" the things the SE is tracking, or the key it's going to destroy. (and it's going to send low-level commands to the flash controller to erase every cell in which the key has ever been stored.)
(a) It's evidence. They cannot "drill into it".
(b) Apple designed to the processor to resist such attempts. (it's actually codified in FIPS-140 standards) It's hardened against x-ray imaging.
In theory, by providing a different firmware for the Secure Enclave (isolated processor) that ignores the "erase me" bit, and does not introduce any per-attempt delays. And then provide a second "app" to allow electronic entry of passcodes (via USB, bluetooth, etc.) They can certainly write that, but getting it into the sterile environment of evidence (run entirely from RAM, touch nothing else) may not be possible.
Because what they need is built into the main processor (specifically the crypto logic) with ZERO interfaces for retrieving it. The flash chip is AES-256 encrypted. It will take, literally, an eternity to break it. (and no, one cannot recover the key via x-ray imaging.)