Most modems nowadays (Sat, Cable, DSL) don't bother with a user/pass from you just to get itself online, because it originates from a physical point-of-presence - specifically, your home address.
Cable is a shared medium. It uses BPI+ yet the initial handshake is still very much faith based.
DSL in some ways is more physically secure because unlike cable there is no shared medium. Every link is point to point. They often use MAC or PPPoE schemes with crummy authentication protocols. This is done more for management purposes than actual security.
There are a few problems with client certs as used with HTTPS. The first is that it's difficult to integrate the selection of a client cert with the login UI.
The problem with client certs there is no defined means of filtering out relevant certificate(s) for site one is visiting.
For example lets say I have 100 client certs for 100 different sites. Each time I visit a site I'm prompted for which of the 100 certs I want to use. If I pick the wrong one TLS handshake fails and I get to try again. If I pick a compatible one or chose none them I'm stuck with that decision until browser restart.
Most browsers don't even provide basic facilities to manage client certs such as remembering or internally applying filters such that the second time I visit site 54 I get site 54's client cert not a pick list of 100 certs.
They also fail to allow client cert selection to be modified while browser is running. If I'm visiting a site and chose not to use my client cert there is no way for me to upgrade to using a client cert. Or if I have multiple client certs for the same site there is no way for me to select a different cert. Each change normally requires complete restart of browser to facilitate.
These are all problems that can be trivially overcome with minimal effort.
UI. Actually, in most browsers, it's pretty hard to have multiple client certs for a single web site at all (try it some time).
The browser has no clue to begin with what certs are applicable to what sites so whether you have 100 for the same site or 1 for each of 100 sites the browser can't tell the difference.
What is difficult is changing client certificates if you have multiple for a site as this requires a total restart of most browsers to facilitate.
Second, the JavaScript APIs for generating and installing client certs are pretty horrible.
The JavaScript APIs are pointless and should be ignored. Little point in not having sites issue certs directly during onboarding process.
It also requires that the client cert be used as part of every TLS handshake in every HTTPS connection, which adds some latency when you're doing multiple requests to the same site.
Session resumption works the same regardless with no additional subsequent round trips.
Nanny state to ensure your HIPPA and PCI and SOX compliant servers at work do not have rootkits?
If a system is rooted once a computer is booted then a few things MUST be true:
1. You've already epically failed. It's game over right there and then. Talk about what happens next is mightily irrelevant. 2. See 1. 3. See 1. 4. Unless vulnerability is found and fixed secure boot won't do shit to prevent the rootkit from being re-loaded upon next boot the same way it was loaded initially.
I very much fail to see the point here. The only conclusion I could draw that would make any sense is when you get owned you can get away with tempting fate and not have to completely rollback system / rebuild all of your shit otherwise secure boot seems to be an exceedingly pointless waste of time.
There is a much easier and much more secure way to handle this that does not require any cryptographic bullshit. Deny capability to modify OS image via hardware latch and don't allow any hardware to incorporate persistent storage that can be modified in the field.
The real reason for secure boot isn't security. It's exclusively about locking out users in order to dictate terms.
IT departments require UEFI secureboot with custom add in keys for their servers which Redhat and FreeBSD support I may add is to make sure you keep your job.
Box checking jobs sure do pay well regardless of predictably feckless results.
For confidentiality and integrity, the top two things an OS can do to help is limit the attack surface (such as not running unnecessary daemons or other software) and provide quick, reliable updates.
Confidentiality is having everything you do uploaded to the worlds most prolific data collection and advertising agency?
Talking confidentiality and integrity on a system that clearly isn't trustworthy in the first place is a waste of time.
The only code that can't possibly be hacked is code that isn't there, so the most secure system is the most minimal system.
Fundamentally misguided. Amount of code is not as important as organization of code.
Real-life attacks use known vulnerabilities 99.99% of the time, so quick, automatic updates to resolve known issues are very important.
Well over 90% of attacks exploit users not systems.
There is one Linux distribution that stands out for avoiding any unnecessary code (and potential vulnerabilities) and providing quick, reliable updates. That distribution is ChromeOS.
Only realistic hope in the near term is better hardware and isolation at hypervisor level.
....They do kinda have a point. Hear me out. In a prior life, I worked with a company providing VoIP phone systems for companies to bypass the traditional telecom system. One of our biggest issues (somewhat mitigated since in the last few years as I understand) that we encountered in deployments was the ridiculous variability in latency, which is tiny for web browsing but horrible for real-time communications.
Sure, we turned on QoS and quickly learned that it's pretty much ignored upstream.
This argument makes no logical sense because in your case you were using the public Internet to provide service over domains you had little to no control over.
This is not what Comcast is doing. They are hosting unique services on their own network from within their own administrative domain towards the customer.
If the ISP is providing telephone service over the customer's Internet infrastructure then there are no issues here because the customer's router can do QoS to prioritize whatever traffic they want and it WILL work.
IF real regulations were written to allow prioritization for real-time AV services that were implemented in a neutral fashion, I could support that.
The whole point of ban on paid prioritization is prevention of exactly this type of leveraging of the ISPs position.
The end user is just as much a part of the public "Internet" as Bing or MySpace. Packets crossing administrative boundary between Comcast's network and customer's Internet network over customers public Internet address and customer's Internet infrastructure is no different than packets crossing boundary between Comcast and Level3.
The locality of ISP provided services already affords the ISP plenty of baked-in advantage AS-IS without granting them cover to artificially benefit themselves at the expense of competitors originating from a different network.
Twitter does the same damned things Facebook does. There are Twitter trackers on every page. (Even this one.) They collect user data without consent. They sell it to advertisers. They run facial recognition on every image uploaded. They have "shadow profiles" of non-Twitter users.
So why just Facebook?
I think we all know the real reason.
It's strategery.
Had you started with twitter #DeleteFacebook wouldn't work.
Speaking for myself all of this downtime for no tangible benefit isn't worth it nor is constantly dealing with the aftermath of what broke or changed behind your back this time. Computers are supposed to be tools.. vehicles to get shit done yet vendors seem hell bent on wasting everyone's time with nonsense.
I must say being impressed with 30 minutes of downtime in the age when production systems can be migrated across physical systems with seconds or less of downtime is like being awarded a medal for crossing the finish line hours after everyone went home and roads re-opened to vehicle traffic.
Exponents protect secrets. Factors are window dressing designed to make things look nice.
I personally think everyone should use amplification because it really does make guessing more difficult with no substantive downsides.
Yet at the same time to conclude failure to use amplification means "poorly secured" is comically wrong.
The fact operations are repeated thousands of times over always elicits those who bring up obvious point really takes x times more resources to obtain a result.
Yet it is not so clear what the relevance is. So what if it takes a day vs a few minutes or months vs few hours or the difference between doing it yourself vs farming the job out to thousands or millions of processors?
At the end of the day calculus is not significantly changed regardless of whether amplification is used or not.
1. Those with low entropy keys should be worried.
2. Those with high entropy keys are better off finding something else to worry about.
The more bits you add to the search space more worthless amplification schemes look in comparison.
Neither of these statements is particularly precise, but the first is general enough that your response starting with "no" is less correct. TCP is very sensitive to loss. These are my favorite links on this subject:
Jitter is not the same thing as packet loss (PL). My response is about Jitter not packet loss.
When I said "Jitter and even packet loss are often concealed by the receive window depending on where event occurs" this means TCP has machinery capable of dealing with out of order receipt and sequence gaps in most cases without stalling the stream for round trip or worse RTO. Mentioning PL was intended only to highlight this capability.
It sure as heck does not mean TCP congestion algorithms should ignore congestion indications in the form of PL. Even a small percent PL to borrow a phrase from Joe is "a big fucking deal" shit had better slow down dramatically in that case. I only mention PL at all to illustrate a point about designed capability of TCP.
Real time communications systems generally have a "jitter buffer" reserving some delay up front in order to allocate time to reorder packets if necessary. This simply doesn't exist in any practical way with streaming of static content.
Depends entirely on what is used for flow-control and how much buffering is done. Jitter can have minimal effect on that or it can shoot things to hell.
No it doesn't. The streaming services use TCP. Jitter and even packet loss are often concealed by the receive window depending on where event occurs. It's a statistical game where to win you need only a buffer big enough to account for transient conditions and of course channel capacity larger than consumption rate.
Massive jitter or packet loss at tail can indeed stall a stream and even result in visually affecting output yet TCP protocol is reasonably well designed and capable of efficient bulk transmission which is all that is necessary for video streaming services.
Remember parents comment was "Video is very susceptible to jitter" which is simply false despite ones ability to concoct ridiculous scenario where jitter becomes service affecting.
It would fit the same profile and no - SNI requires the traffic to be decrypted. If you're able to distinguish that, then the encryption is utterly broken.
SNI is transmitted in the clear for the simple reason servers absolutely need to know a hostname in order to determine what certificates it needs to load to communicate with the client. Certificates often managed and owned by completely separate customers of the hosting provider.
There have been proposals to obscure SNI behind some kind of anonymous DH scheme yet even in TLS 1.3 as it is this is still done in the clear. Currently SNI on all production systems is performed in the clear.
If most streaming used TCP, there would be all kinds of buffering and slowdowns. I think you're wrong.
ALL of them use TCP.
Confusion likely stems from mistaking realtime bidirectional communications such as voice and video calling which are inherently delay intolerant with bulk transfer of static content. Two completely different technologies with very little in common.
The way you keep from buffering and slowing down is by creating a large enough stream buffer to hedge against presence of any future transient conditions.
We've had our tap water tested against bottled, and it's better in all respects. A tad hard, good Magnesium content, and the taste is right up there with pure spring water from the local mountains.
But did you have it tested against Fiji water?
Just remember folks, that Bottled water you just paid 3 bucks for 12 ounces was bottled by a company that can make more money the cheaper they produce the stuff. Since most people are convinced it is better for us, they'll keep buying it no matter what.
Slashdot Mirror
Most modems nowadays (Sat, Cable, DSL) don't bother with a user/pass from you just to get itself online, because it originates from a physical point-of-presence - specifically, your home address.
Cable is a shared medium. It uses BPI+ yet the initial handshake is still very much faith based.
DSL in some ways is more physically secure because unlike cable there is no shared medium. Every link is point to point. They often use MAC or PPPoE schemes with crummy authentication protocols. This is done more for management purposes than actual security.
There are a few problems with client certs as used with HTTPS. The first is that it's difficult to integrate the selection of a client cert with the login UI.
The problem with client certs there is no defined means of filtering out relevant certificate(s) for site one is visiting.
For example lets say I have 100 client certs for 100 different sites. Each time I visit a site I'm prompted for which of the 100 certs I want to use. If I pick the wrong one TLS handshake fails and I get to try again. If I pick a compatible one or chose none them I'm stuck with that decision until browser restart.
Most browsers don't even provide basic facilities to manage client certs such as remembering or internally applying filters such that the second time I visit site 54 I get site 54's client cert not a pick list of 100 certs.
They also fail to allow client cert selection to be modified while browser is running. If I'm visiting a site and chose not to use my client cert there is no way for me to upgrade to using a client cert. Or if I have multiple client certs for the same site there is no way for me to select a different cert. Each change normally requires complete restart of browser to facilitate.
These are all problems that can be trivially overcome with minimal effort.
UI. Actually, in most browsers, it's pretty hard to have multiple client certs for a single web site at all (try it some time).
The browser has no clue to begin with what certs are applicable to what sites so whether you have 100 for the same site or 1 for each of 100 sites the browser can't tell the difference.
What is difficult is changing client certificates if you have multiple for a site as this requires a total restart of most browsers to facilitate.
Second, the JavaScript APIs for generating and installing client certs are pretty horrible.
The JavaScript APIs are pointless and should be ignored. Little point in not having sites issue certs directly during onboarding process.
It also requires that the client cert be used as part of every TLS handshake in every HTTPS connection, which adds some latency when you're doing multiple requests to the same site.
Session resumption works the same regardless with no additional subsequent round trips.
What a brilliant idea. Lets all come up with a "secure" web authentication feature that doesn't actually allow for secure password authentication.
Just for fun lets toss in "User Consent" and "User Presence" because "security".
And to complete our incompetence... channel bindings? What channel bindings?
Nanny state to ensure your HIPPA and PCI and SOX compliant servers at work do not have rootkits?
If a system is rooted once a computer is booted then a few things MUST be true:
1. You've already epically failed. It's game over right there and then. Talk about what happens next is mightily irrelevant.
2. See 1.
3. See 1.
4. Unless vulnerability is found and fixed secure boot won't do shit to prevent the rootkit from being re-loaded upon next boot the same way it was loaded initially.
I very much fail to see the point here. The only conclusion I could draw that would make any sense is when you get owned you can get away with tempting fate and not have to completely rollback system / rebuild all of your shit otherwise secure boot seems to be an exceedingly pointless waste of time.
There is a much easier and much more secure way to handle this that does not require any cryptographic bullshit. Deny capability to modify OS image via hardware latch and don't allow any hardware to incorporate persistent storage that can be modified in the field.
The real reason for secure boot isn't security. It's exclusively about locking out users in order to dictate terms.
IT departments require UEFI secureboot with custom add in keys for their servers which Redhat and FreeBSD support I may add is to make sure you keep your job.
Box checking jobs sure do pay well regardless of predictably feckless results.
Well in this case Pbkdf2 would provide at least 10,000 to 50,000 times more protection than their approach for the same password.
So what?
It's weird, I mean, it's like 3 lines of C# (and probably many other languages) to convert a string to a secure Pbkdf2 hash.
Pbkdf2 is only as "secure" as the password it protects.
Instead of helping them to make drone strikes more accurate, let's let the Pentagon continue to hit civilian bystanders too.
I suspect Jevons paradox may also apply to drones.
For confidentiality and integrity, the top two things an OS can do to help is limit the attack surface (such as not running unnecessary daemons or other software) and provide quick, reliable updates.
Confidentiality is having everything you do uploaded to the worlds most prolific data collection and advertising agency?
Talking confidentiality and integrity on a system that clearly isn't trustworthy in the first place is a waste of time.
The only code that can't possibly be hacked is code that isn't there, so the most secure system is the most minimal system.
Fundamentally misguided. Amount of code is not as important as organization of code.
Real-life attacks use known vulnerabilities 99.99% of the time, so quick, automatic updates to resolve known issues are very important.
Well over 90% of attacks exploit users not systems.
There is one Linux distribution that stands out for avoiding any unnecessary code (and potential vulnerabilities) and providing quick, reliable updates. That distribution is ChromeOS.
Only realistic hope in the near term is better hardware and isolation at hypervisor level.
They built the network, they maintain the network, they own it, they set the rules. I'm not sure why you think you have any say in the matter.
Most likely because I pay for Internet service, vote and have made my views on NN known to my representatives?
Don't like it?
What was your first clue?
Write a check for a few billion and build your own network.
Quite certain it would bounce.
....They do kinda have a point. Hear me out. In a prior life, I worked with a company providing VoIP phone systems for companies to bypass the traditional telecom system. One of our biggest issues (somewhat mitigated since in the last few years as I understand) that we encountered in deployments was the ridiculous variability in latency, which is tiny for web browsing but horrible for real-time communications.
Sure, we turned on QoS and quickly learned that it's pretty much ignored upstream.
This argument makes no logical sense because in your case you were using the public Internet to provide service over domains you had little to no control over.
This is not what Comcast is doing. They are hosting unique services on their own network from within their own administrative domain towards the customer.
If the ISP is providing telephone service over the customer's Internet infrastructure then there are no issues here because the customer's router can do QoS to prioritize whatever traffic they want and it WILL work.
IF real regulations were written to allow prioritization for real-time AV services that were implemented in a neutral fashion, I could support that.
As Admiral Ackbar would say...
The whole point of ban on paid prioritization is prevention of exactly this type of leveraging of the ISPs position.
The end user is just as much a part of the public "Internet" as Bing or MySpace. Packets crossing administrative boundary between Comcast's network and customer's Internet network over customers public Internet address and customer's Internet infrastructure is no different than packets crossing boundary between Comcast and Level3.
The locality of ISP provided services already affords the ISP plenty of baked-in advantage AS-IS without granting them cover to artificially benefit themselves at the expense of competitors originating from a different network.
Twitter does the same damned things Facebook does. There are Twitter trackers on every page. (Even this one.) They collect user data without consent. They sell it to advertisers. They run facial recognition on every image uploaded. They have "shadow profiles" of non-Twitter users.
So why just Facebook?
I think we all know the real reason.
It's strategery.
Had you started with twitter #DeleteFacebook wouldn't work.
What I find amusing about this whole thing is that the Trump campaign never used the data, because they didn't trust it.
Perhaps you should re-read article you posted. This is NOT what it says.
"Cambridge Analytica data was used for some targeted digital advertising and a large TV buy"
So Facebook giving all that data to the Trump campaign had no effect on the election whatsoever.
1. Facebook didn't give it to Trump.
2. Article you cited says data was used.
3. Whether it had an effect or not is irrelevant.
All this outrage and calls for regulation and boycotting - because it was Trump of course - over something that Trump didn't use.
Some simply grasp for excuses to pounce because they hate Trump.
Some are concerned by revelations of how their data is being used. Perhaps belated contemplating issues they should have thought about much earlier.
Yet others read about Nix and his Ukrainian girls and it's just another log on the fire. There are many dimensions to the story.
Please submit your suggestions using hash tag #DeleteFacebook winner will be announced during next Facebook shareholder meeting.
- Fuckerville
- Slavetown
- Pwn3dville
- New Pyongyang
- Dusttopia
- Stalkerville
- Airstrip Two
- Creepertown
Speaking for myself all of this downtime for no tangible benefit isn't worth it nor is constantly dealing with the aftermath of what broke or changed behind your back this time. Computers are supposed to be tools.. vehicles to get shit done yet vendors seem hell bent on wasting everyone's time with nonsense.
I must say being impressed with 30 minutes of downtime in the age when production systems can be migrated across physical systems with seconds or less of downtime is like being awarded a medal for crossing the finish line hours after everyone went home and roads re-opened to vehicle traffic.
Nice to see the message of what Facebook has always been seeing the light of day despite selfish hypocrisy driving it.
Also nice to see "social media" getting some love by lynch mobs they've had a hand in cultivating all these years.
1) Using SHA-1 in this day and age; and
There is nothing wrong with use of SHA-1 in this context based on publically available information about shortcomings of SHA-1.
Exponents protect secrets.
Factors are window dressing designed to make things look nice.
I personally think everyone should use amplification because it really does make guessing more difficult with no substantive downsides.
Yet at the same time to conclude failure to use amplification means "poorly secured" is comically wrong.
The fact operations are repeated thousands of times over always elicits those who bring up obvious point really takes x times more resources to obtain a result.
Yet it is not so clear what the relevance is. So what if it takes a day vs a few minutes or months vs few hours or the difference between doing it yourself vs farming the job out to thousands or millions of processors?
At the end of the day calculus is not significantly changed regardless of whether amplification is used or not.
1. Those with low entropy keys should be worried.
2. Those with high entropy keys are better off finding something else to worry about.
The more bits you add to the search space more worthless amplification schemes look in comparison.
Neither of these statements is particularly precise, but the first is general enough that your response starting with "no" is less correct. TCP is very sensitive to loss. These are my favorite links on this subject:
Jitter is not the same thing as packet loss (PL). My response is about Jitter not packet loss.
When I said "Jitter and even packet loss are often concealed by the receive window depending on where event occurs" this means TCP has machinery capable of dealing with out of order receipt and sequence gaps in most cases without stalling the stream for round trip or worse RTO. Mentioning PL was intended only to highlight this capability.
It sure as heck does not mean TCP congestion algorithms should ignore congestion indications in the form of PL. Even a small percent PL to borrow a phrase from Joe is "a big fucking deal" shit had better slow down dramatically in that case. I only mention PL at all to illustrate a point about designed capability of TCP.
Real time communications systems generally have a "jitter buffer" reserving some delay up front in order to allocate time to reorder packets if necessary. This simply doesn't exist in any practical way with streaming of static content.
Depends entirely on what is used for flow-control and how much buffering is done. Jitter can have minimal effect on that or it can shoot things to hell.
No it doesn't. The streaming services use TCP. Jitter and even packet loss are often concealed by the receive window depending on where event occurs. It's a statistical game where to win you need only a buffer big enough to account for transient conditions and of course channel capacity larger than consumption rate.
Massive jitter or packet loss at tail can indeed stall a stream and even result in visually affecting output yet TCP protocol is reasonably well designed and capable of efficient bulk transmission which is all that is necessary for video streaming services.
Remember parents comment was "Video is very susceptible to jitter" which is simply false despite ones ability to concoct ridiculous scenario where jitter becomes service affecting.
It would fit the same profile and no - SNI requires the traffic to be decrypted. If you're able to distinguish that, then the encryption is utterly broken.
SNI is transmitted in the clear for the simple reason servers absolutely need to know a hostname in order to determine what certificates it needs to load to
communicate with the client. Certificates often managed and owned by completely separate customers of the hosting provider.
There have been proposals to obscure SNI behind some kind of anonymous DH scheme yet even in TLS 1.3 as it is this is still done in the clear. Currently SNI on all production systems is performed in the clear.
If most streaming used TCP, there would be all kinds of buffering and slowdowns. I think you're wrong.
ALL of them use TCP.
Confusion likely stems from mistaking realtime bidirectional communications such as voice and video calling which are inherently delay intolerant with bulk transfer of static content. Two completely different technologies with very little in common.
The way you keep from buffering and slowing down is by creating a large enough stream buffer to hedge against presence of any future transient conditions.
Video is very susceptible to jitter
No it isn't.
The ONLY solution they should be considering is properly pricing energy.
We've had our tap water tested against bottled, and it's better in all respects. A tad hard, good Magnesium content, and the taste is right up there with pure spring water from the local mountains.
But did you have it tested against Fiji water?
Just remember folks, that Bottled water you just paid 3 bucks for 12 ounces was bottled by a company that can make more money the cheaper they produce the stuff. Since most people are convinced it is better for us, they'll keep buying it no matter what.
Fiji water is magical. I'm convinced of it.