From the synopsis it does seem like Cisco is not providing a fix for this issue, only a "potential" workaround (meaning they baked it in and there are other methods of exploiting the same issue).
Although the SCOTUS agrees with you, there hasn't been any legally binding decision made surrounding these issues, lower courts have typically established that providing some assistance to your own conviction is acceptable.
The 'true' solution would be to create a password/passphrase that requires you to actively participate with your mind. Eg. - I can only unlock this password by doing some sort of obstacle course with each stop providing me parts of the passwords.
It has been established that you can't be forced to turn over the numbers to your combination lock while you can be compelled to provide the physical key if you have it. The problem is that in cryptography, we call it a key but we mean combination lock, the judges here ruled a cryptographic "key" is something similar to a physical key, a piece of code/hardware you can give them to unlock your "safe" while it's actually a combination lock.
a) You can get multiple certificates from multiple CA's for the same domain for good reason (say you want to switch providers or have multiple servers you need to secure). An SSL certificate only establishes a weak verification of ownership and no relationship whatsoever to your IP or a particular system. b) You would have to trust and be able to scan hundreds of CA's containing millions of SSL certificates. Most blockchains take anywhere from 2-10 minutes to do a verification, can take up to days or weeks to update and we're talking about a blockchain that would have to be thousands of times larger than Bitcoin. c) There is actually a mechanism in place to verify the SSL cert with a CA right now, as with the above, the amount of roundtrips, delays and variations of implementations make it a hard thing to do. Some servers have integrated OCSP stapling but it's nowhere near universal.
As you say, you have to insert the DNS trust anchor in the OS, just like you insert the CA in every OS you control for these proxies to work. Re-signing or filtering out the DNSSEC for a request is trivial at that point (basically make it appear as if the entire DNS tree doesn't have DNSSEC).
Because they all have the same problems and don't fix any of the article's problems. I can repackage google.com's DNS response and sign it with my own DNS key, as long as the clients of my server(s) 'trust' that I am Google, they will accept it as such and that is the entire point of security.
The simplest fix for these issues is to simply delete your company's and Microsoft's CA (if they use AD) from your computer - problem solved, it will no longer trust your company and you probably won't be able to get on the Internet either.
There is no physical way of avoiding MITM if you trust the Man that sits In The Middle. Even quantum physics can't help you.
An immutable database doesn't help here. This is about the intentional breaking of security for whatever reason. It's similar to you installing malware on your computer, you can't prevent stupid people from doing stupid stuff.
CA's are supposed to be responsible for the trust of a certificate. Even if a bank were to print out their certificate hash, you can technically generate another certificate with the same hash and you would also have to trust the $10/h teller and the branch's printer - I'd much rather trust they have a good sysadmin that made a good choice in CA than a network of unrelated people that have no clue.
The problem with SSL-unpacking proxies is the following: - You can't pass along the original SSL certificates, so your clients all have to trust the SSL proxy - You can't verify with your clients whether the SSL certificate is correct, so you have to either accept or deny all 'broken' SSL certificates. - Since a significant portion of SSL implementations are expected to be broken (especially once you start dealing with parties like Microsoft, IBM and Oracle), your implementation also has to be broken.
It's not an implementation error, it's an unavoidable feature of these SSL inspection proxies. You basically have to trust everything coming through the proxy, remove the capability of handling or inspecting the security yourself and give up the notion that it's safe, secure and unchanged - that is the feature the people in charge of security over these organizations *want*.
On the other hand, if an SSL vulnerability crops up, upgrading your browser (or the requirement to) doesn't matter anymore and you have to downgrade your security to the lowest common denominator in security (which is most likely Windows XP, Internet Explorer 6 or Java 6) for your entire organization because if you don't, those things won't work anymore.
The open solution are pretty close to perfect. I get a much better detection and block rate (99%) on private servers than my Google account (80-90%). I occasionally get a clueless Exchange admin that wonders why their IP is on a block list but even then, the user gets the email encapsulated with a big warning and the admin gets a lesson in SMTP 101.
Only if the spammer doesn't use the same server/service as your sender or hasn't set up DMARC/SPF themselves. E-mail was built to be decentralized and robust, there are two problems with the current approaches:
DMARC/SPF - pretty much any anti-spam - relies on the cooperation of both senders and/or receivers and making things less robust so you can "break" the robustness for bad people and keep it in tact for good people. You require the cooperation of a significant number of people to keep sort of trust up including the clueless user and often the spammers as well.
The other problem is that the current Internet is centralized across a handful of services. You can't establish or break a trust with Gmail.com for example without either blocking the good ones or allowing the bad ones.
And then you're blocking pretty much any corporate user of O365 or any number of Microsoft "server" product users or anyone using built-by-stupid products like MailChimp, or similar "cloudy" "service as a service" providers you see advertised.
DMARC has been around for pretty much 2 decades, if it hasn't been picked up now, it never will.
The poverty line in the US is actually quite high and until you make a significant percentage above that, you can get all sorts of aid from the government. There is no reason anyone in this country goes hungry besides due to participation in illegal activities or a history of living well beyond ones means.
Wrong: You don't need a driver for a newer CPU unless you're planning on supporting it's new features. The MS-DOS kernel will boot on the Kaby Lake or Ryzen architecture and that hasn't been updated in decades.
This is Microsoft's logic:
- Not enough people are using our ad-ware platform - Let's push ads so people see our new ad-ware - That didn't work - Let's push an update that doesn't have a button to not update to our new ad-ware - That didn't work - Let's push an update that self-upgrades to our new ad-ware. - That didn't work - Let's push an update that breaks the OS unless they accept our new ad-ware whenever they upgrade the hardware
Unpatched Win7 and WinXP SP3 will run on these new CPU's - it's just later non-hardware related updates that break.
Giving people paid time off doesn't mean they have to make it up somewhere else. Seems to me like your employer is an abusive fuck and got what they deserved. Giving people paid time off in advance is "nice" and your employer wasn't obligated to do that, on the other hand, making them work overtime to make up for paid time off you allowed them or have to give them in the first place is abusive.
I get ~12h/month paid time off contractually, that doesn't mean I am obligated to make it up if I take my time off and if I work beyond 40 hours they do indeed have to pay overtime. I am salaried and my employer would still have to give me ~1h break time per day and if I work more than 8h I would have to get additional break times and I can't be made to work more than 10 or 12 hours/day and 40 hours/week without overtime. The benefit to being salaried is just that I don't have to punch a clock and on the other hand it would be slightly harder for me to prove that I'm being coerced to work more than allowed without being paid overtime.
The problem is that it's logically the same architecture. Kaby Lake CPU's can boot into CP/M or OS/2 because it has an x86 emulation layer and supports all the instruction sets since the 8088. You may not be able to use all the fancy new things in the CPU, but it will work.
"Not supported" means - we won't work on giving you access to the newest instruction sets (if they have a new AVX or AES instruction set for example), it doesn't mean, we'll add code to check for a CPUID and refuse to boot. "Not supported" means, we won't fix the damned thing if it breaks, not, we'll intentionally break it so you're forced to upgrade.
The problem here is they have to add code to their "unsupported OS" specifically to break things. If they have the time to add and test code to do that, they would have time to properly support it.
I didn't yet get into the details of the story, but I think this is the lawsuit that started a few years ago where people having a contract and paying for Gmail (eg. business and education) were promised they weren't going to be scanned yet Google continued scanning them regardless. This was quite a kerfuffle for a few Universities a few years back.
I don't think the problem would be with the material if they didn't keep casting the same tired actors and directors. The Matrix worked because it was new material from a pair of relatively new directors. Firefly worked for the same reasons but those people burn out doing the same tired shit over and over.
a) Farming is relatively cheap. It's an easy way to make proteins and other nutrients without having to grow or store high varieties crops and the headaches associated with it. Whether or not lab-grown meat will be cheaper will highly depend on the process, I don't think initially it would be any cheaper because you have a huge investment and marketing cost, once those things are figured out, it may be cheaper, again, depending on what goes in it. Meat is just (vegetables + water + sunlight), cows and pigs aren't bred because they are the best tasting meat but due to the simplicity of farming them and they eat things we don't (grass, maize and blemished foods). Most likely this "meat" will require nutrients + water + energy to make as well, initially more, maybe less over time.
b) Human beings are omnivores, not herbivores. We're not "supposed" to eat meat? Our biologies suggest otherwise, we would puke if we couldn't eat it. We're not carnivores either but we do have the digestive enzymes to process meat. Other primates are omnivores as well although most of the time meat isn't available, they WILL eat meat, including insects, eggs and other animal products, even cannibalize.
c) The easy availability of meat and eventually cooked meat had a huge impact on our evolution as less time was spent gathering and processing food, processing vegetables is very energy consuming and the reason many pure vegans have health problems. We're definitely not "supposed" to eat 1000 kg/year worth of meat, that's relatively modern (last 100-200 years if you weren't obscenely rich) but on the other hand McDonalds/Taco Bell is hardly considered meat when up to 60% is soy.
Cherry-picking research from a blog doesn't help your rabid adherence to an illogical viewpoint. If we're truly a pure vegetarian/vegan species, then why does pretty much every vegan/vegetarian need food supplements?
Lockout procedures, unlike common expectations are just a software switch. I learned that ~20 years ago in industrial automation class from a Volvo factory - in school we were always taught to electrically wire the emergency stop buttons, in real life factories shutting something down and encapsulating that other parts of the line can be unresponsive is too costly to implement such fault states in software, the cost/risk of human loss is less than a few extra days of programming teams.
For various reasons including avoiding US taxes and generating localized ad revenue directly, Facebook does have holdings in various countries including Germany. Thus they are (partially) a German company and thus have to adhere to local laws. Facebook could easily avoid this by repatriating all it's holdings and income to the US, whether that is good for the US, Facebook or German economies is an entirely different question.
Slashdot Mirror
From the synopsis it does seem like Cisco is not providing a fix for this issue, only a "potential" workaround (meaning they baked it in and there are other methods of exploiting the same issue).
Although the SCOTUS agrees with you, there hasn't been any legally binding decision made surrounding these issues, lower courts have typically established that providing some assistance to your own conviction is acceptable.
The 'true' solution would be to create a password/passphrase that requires you to actively participate with your mind. Eg. - I can only unlock this password by doing some sort of obstacle course with each stop providing me parts of the passwords.
It has been established that you can't be forced to turn over the numbers to your combination lock while you can be compelled to provide the physical key if you have it. The problem is that in cryptography, we call it a key but we mean combination lock, the judges here ruled a cryptographic "key" is something similar to a physical key, a piece of code/hardware you can give them to unlock your "safe" while it's actually a combination lock.
And as you said, this is a single-vendor workaround and works only if you're interactive.
a) You can get multiple certificates from multiple CA's for the same domain for good reason (say you want to switch providers or have multiple servers you need to secure). An SSL certificate only establishes a weak verification of ownership and no relationship whatsoever to your IP or a particular system.
b) You would have to trust and be able to scan hundreds of CA's containing millions of SSL certificates. Most blockchains take anywhere from 2-10 minutes to do a verification, can take up to days or weeks to update and we're talking about a blockchain that would have to be thousands of times larger than Bitcoin.
c) There is actually a mechanism in place to verify the SSL cert with a CA right now, as with the above, the amount of roundtrips, delays and variations of implementations make it a hard thing to do. Some servers have integrated OCSP stapling but it's nowhere near universal.
As you say, you have to insert the DNS trust anchor in the OS, just like you insert the CA in every OS you control for these proxies to work. Re-signing or filtering out the DNSSEC for a request is trivial at that point (basically make it appear as if the entire DNS tree doesn't have DNSSEC).
Because they all have the same problems and don't fix any of the article's problems. I can repackage google.com's DNS response and sign it with my own DNS key, as long as the clients of my server(s) 'trust' that I am Google, they will accept it as such and that is the entire point of security.
The simplest fix for these issues is to simply delete your company's and Microsoft's CA (if they use AD) from your computer - problem solved, it will no longer trust your company and you probably won't be able to get on the Internet either.
There is no physical way of avoiding MITM if you trust the Man that sits In The Middle. Even quantum physics can't help you.
An immutable database doesn't help here. This is about the intentional breaking of security for whatever reason. It's similar to you installing malware on your computer, you can't prevent stupid people from doing stupid stuff.
CA's are supposed to be responsible for the trust of a certificate. Even if a bank were to print out their certificate hash, you can technically generate another certificate with the same hash and you would also have to trust the $10/h teller and the branch's printer - I'd much rather trust they have a good sysadmin that made a good choice in CA than a network of unrelated people that have no clue.
The problem with SSL-unpacking proxies is the following:
- You can't pass along the original SSL certificates, so your clients all have to trust the SSL proxy
- You can't verify with your clients whether the SSL certificate is correct, so you have to either accept or deny all 'broken' SSL certificates.
- Since a significant portion of SSL implementations are expected to be broken (especially once you start dealing with parties like Microsoft, IBM and Oracle), your implementation also has to be broken.
It's not an implementation error, it's an unavoidable feature of these SSL inspection proxies. You basically have to trust everything coming through the proxy, remove the capability of handling or inspecting the security yourself and give up the notion that it's safe, secure and unchanged - that is the feature the people in charge of security over these organizations *want*.
On the other hand, if an SSL vulnerability crops up, upgrading your browser (or the requirement to) doesn't matter anymore and you have to downgrade your security to the lowest common denominator in security (which is most likely Windows XP, Internet Explorer 6 or Java 6) for your entire organization because if you don't, those things won't work anymore.
The open solution are pretty close to perfect. I get a much better detection and block rate (99%) on private servers than my Google account (80-90%). I occasionally get a clueless Exchange admin that wonders why their IP is on a block list but even then, the user gets the email encapsulated with a big warning and the admin gets a lesson in SMTP 101.
Spam is profitable enough to bear that risk. Even if your kneecaps get a bullet in them, you still get a nice mansion to live in.
It is but the configuration isn't directly editable and seems to be both made by and targeted towards the clueless end user. (TiVo-ization)
Only if the spammer doesn't use the same server/service as your sender or hasn't set up DMARC/SPF themselves. E-mail was built to be decentralized and robust, there are two problems with the current approaches:
DMARC/SPF - pretty much any anti-spam - relies on the cooperation of both senders and/or receivers and making things less robust so you can "break" the robustness for bad people and keep it in tact for good people. You require the cooperation of a significant number of people to keep sort of trust up including the clueless user and often the spammers as well.
The other problem is that the current Internet is centralized across a handful of services. You can't establish or break a trust with Gmail.com for example without either blocking the good ones or allowing the bad ones.
And then you're blocking pretty much any corporate user of O365 or any number of Microsoft "server" product users or anyone using built-by-stupid products like MailChimp, or similar "cloudy" "service as a service" providers you see advertised.
DMARC has been around for pretty much 2 decades, if it hasn't been picked up now, it never will.
The poverty line in the US is actually quite high and until you make a significant percentage above that, you can get all sorts of aid from the government. There is no reason anyone in this country goes hungry besides due to participation in illegal activities or a history of living well beyond ones means.
Wrong: You don't need a driver for a newer CPU unless you're planning on supporting it's new features. The MS-DOS kernel will boot on the Kaby Lake or Ryzen architecture and that hasn't been updated in decades.
This is Microsoft's logic:
- Not enough people are using our ad-ware platform
- Let's push ads so people see our new ad-ware
- That didn't work
- Let's push an update that doesn't have a button to not update to our new ad-ware
- That didn't work
- Let's push an update that self-upgrades to our new ad-ware.
- That didn't work
- Let's push an update that breaks the OS unless they accept our new ad-ware whenever they upgrade the hardware
Unpatched Win7 and WinXP SP3 will run on these new CPU's - it's just later non-hardware related updates that break.
Giving people paid time off doesn't mean they have to make it up somewhere else. Seems to me like your employer is an abusive fuck and got what they deserved. Giving people paid time off in advance is "nice" and your employer wasn't obligated to do that, on the other hand, making them work overtime to make up for paid time off you allowed them or have to give them in the first place is abusive.
I get ~12h/month paid time off contractually, that doesn't mean I am obligated to make it up if I take my time off and if I work beyond 40 hours they do indeed have to pay overtime. I am salaried and my employer would still have to give me ~1h break time per day and if I work more than 8h I would have to get additional break times and I can't be made to work more than 10 or 12 hours/day and 40 hours/week without overtime. The benefit to being salaried is just that I don't have to punch a clock and on the other hand it would be slightly harder for me to prove that I'm being coerced to work more than allowed without being paid overtime.
The problem is that it's logically the same architecture. Kaby Lake CPU's can boot into CP/M or OS/2 because it has an x86 emulation layer and supports all the instruction sets since the 8088. You may not be able to use all the fancy new things in the CPU, but it will work.
"Not supported" means - we won't work on giving you access to the newest instruction sets (if they have a new AVX or AES instruction set for example), it doesn't mean, we'll add code to check for a CPUID and refuse to boot. "Not supported" means, we won't fix the damned thing if it breaks, not, we'll intentionally break it so you're forced to upgrade.
The problem here is they have to add code to their "unsupported OS" specifically to break things. If they have the time to add and test code to do that, they would have time to properly support it.
I didn't yet get into the details of the story, but I think this is the lawsuit that started a few years ago where people having a contract and paying for Gmail (eg. business and education) were promised they weren't going to be scanned yet Google continued scanning them regardless. This was quite a kerfuffle for a few Universities a few years back.
I don't think the problem would be with the material if they didn't keep casting the same tired actors and directors. The Matrix worked because it was new material from a pair of relatively new directors. Firefly worked for the same reasons but those people burn out doing the same tired shit over and over.
a) Farming is relatively cheap. It's an easy way to make proteins and other nutrients without having to grow or store high varieties crops and the headaches associated with it. Whether or not lab-grown meat will be cheaper will highly depend on the process, I don't think initially it would be any cheaper because you have a huge investment and marketing cost, once those things are figured out, it may be cheaper, again, depending on what goes in it. Meat is just (vegetables + water + sunlight), cows and pigs aren't bred because they are the best tasting meat but due to the simplicity of farming them and they eat things we don't (grass, maize and blemished foods). Most likely this "meat" will require nutrients + water + energy to make as well, initially more, maybe less over time.
b) Human beings are omnivores, not herbivores. We're not "supposed" to eat meat? Our biologies suggest otherwise, we would puke if we couldn't eat it. We're not carnivores either but we do have the digestive enzymes to process meat. Other primates are omnivores as well although most of the time meat isn't available, they WILL eat meat, including insects, eggs and other animal products, even cannibalize.
c) The easy availability of meat and eventually cooked meat had a huge impact on our evolution as less time was spent gathering and processing food, processing vegetables is very energy consuming and the reason many pure vegans have health problems. We're definitely not "supposed" to eat 1000 kg/year worth of meat, that's relatively modern (last 100-200 years if you weren't obscenely rich) but on the other hand McDonalds/Taco Bell is hardly considered meat when up to 60% is soy.
Cherry-picking research from a blog doesn't help your rabid adherence to an illogical viewpoint. If we're truly a pure vegetarian/vegan species, then why does pretty much every vegan/vegetarian need food supplements?
Facebook Germany GmbH has their headquarters in Hamburg, they are doing "local ad sales and marketing".
Lockout procedures, unlike common expectations are just a software switch. I learned that ~20 years ago in industrial automation class from a Volvo factory - in school we were always taught to electrically wire the emergency stop buttons, in real life factories shutting something down and encapsulating that other parts of the line can be unresponsive is too costly to implement such fault states in software, the cost/risk of human loss is less than a few extra days of programming teams.
For various reasons including avoiding US taxes and generating localized ad revenue directly, Facebook does have holdings in various countries including Germany. Thus they are (partially) a German company and thus have to adhere to local laws. Facebook could easily avoid this by repatriating all it's holdings and income to the US, whether that is good for the US, Facebook or German economies is an entirely different question.