I touched OpenSSL once. It was a nightmare. No idea where or how it passed anything as it wasn't at all clear the path that simple things, like certificate checking, were supposed to take.
In the end, I hacked onto it rather than play with it. The documentation was non-existent. The code samples were incomplete and with almost zero explanation of what you were supposed to be checking for and where things COULD go wrong. Hence 90% of the code I see that touches OpenSSL looks exactly like the samples and nothing more.
LOL I agree with you the documentation sucks especially when you have any need to go off the SSL_* rails...yet this is niche + free shit and in that context well in line with a number of open source C APIs or generally what I've come to expect.
There is a separate.c file for every command verb you can possibly type from openssl CLI in the apps folder.
I've seen a number of cut and paste jobbers in various projects where authors obviously had taken no time to understand what they were doing yet this is hardly unique to OpenSSL. This kind of thing exists everywhere even where excellent documentation exists.
All I wanted to do was have two x509 certificates, and check that both were valid and one properly signed the other, as part of a primitive DRM scheme I was toying with. It turned into a nightmare scenario of IMAGINING every possible outcome and specifically coding for each one, rather than anything sensible.
Here is where my experience diverges... yes the API could be better, documentation could exist yet these arguments about APIs also applies to using OpenSSL from CLI. For many it is a bunch of magical incantations most people just cut and paste parameters from examples without having a firm grasp of underlying structure. The problem is lack of trivial abstractions tailored to specific use cases to make specific peoples jobs as easy as possible.
The same concepts apply to iptables or ffmpeg... I just want to block an IP or rip a DVD to mkv.. why do I need to know all of this extraneous BS? Well you don't if you used the proper front end/abstraction API. Most systems I've ever screwed with are this way.
Having taken the time to understand how to manage and check certificates using the OpenSSL API.. it was difficult to find information and understand screwy structures like X509_* vs EVP_PKEY but most of my problems were rooted in lack of knowledge in some specifics about how the technology itself worked even though I've used OpenSSL API and CLI in other contexts for years.
The API has never failed me yet in the sense I found myself having to resort to low level drudgery operating on levels far beneath what was ideal and whenever I needed a callback to tweak how OpenSSL worked one was available to me. Not ideal, but hardly unexpected, nightmare or more than what I expected going in.
All caps has the distinct connotation of trying to ram something down people's throats. I'm not ready to swallow that Bush told us something he didn't himself believe ("It's not a lie if you believe it" cf. G. Costanza), but if I could do that how is our current WH exempt from:
Caps was only intended as emphasis if you took it to mean something else I apologize.
In my mind the matter is settled. We have interviews with low level intelligence folk, we have downing street memo, we have Rumsfeld memo...that so many separate threads of dubious evidence... evidence known at the time to be strenuous at best paraded before the country and world as solid fact when no serious subject matter expert believed such at the time is no accident. It is impossible to know everything that went on or what people believed or knew what. I've seen enough BS to make up my own mind quite comfortably.
(1) having the IRS agitate against people for one side of political beliefs and not the other
(2) broad, open warrants
(3) ordering the Syrian embassy security to an artificially low level (Paris had more security on deck)
And then call all of these things "phony scandals"?
I think you are using all capital letters because you realize you are in a little over your head here with your claims.
I have never in my life said anything about any of the above topics. Please add signature drone strikes to Obama's list.
DDOS mitigation services make money. DDOS attack services make money. The people who are targets are not going to do anything other than pay someone to help them stay on the air.
There is not even enough interest to take even reasonable and relatively trivial steps to fix DNS (draft-eastlake-dnsext-cookies-05) instead full steam ahead with DNSSEC we don't care about consequences.
BCP38 adds little additional value should the few broken protocols deployed in sufficient quantity to be useful for DDOS are fixed. The chance of that happening over time in the same way SYN cookies happened is in my view more realistic than expecting operators to implement BCP38 with enough coverage and granularity to be useful.
About those botnet armies of millions of unfortunate souls owned by viruses and malware... who wants to fix that? Security companies would go out of business right and left if millions of PCs ceased to get owned on a regular basis overwhelmingly not by exploiting vulnerabilities or viral propagation but by simple social engineering tricking people to run an attachment or download something from a website.
The perverse thread through all of this is total lack of market based incentive to fix anything. The more dysfunctional the network is to use the more people get paid to deal with the consequences and the more institutional pressure exists to retard progress.
It seems to me if you really cared to move the needle following would be necessary.
1. Replace SMTP.
2. Compel advertising networks to stop being complicit in propagation of malware.
3. Add n00b 1337 options when installing operating systems to give users rope commensurate with their needs and abilities.
Separate jails for browsers and downloads by default would help a lot. What isn't helpful is crap like UAC which does nothing to protect users data/environment or prevent system from being coopted for DDOS.
Isolated application model of mobile devices could also be helpful when architected to support rather than exploit end users.
I can't see how employee's SSN's will improve the open source codebase.
Why are SSN's permanent life-long secret codes only the people who represent them should know?
I think in aggregate if everyone's SSN were made public it would prevent a vast sea of morons from relying on them for purposes for which they were neither intended or suitable and everyone would be better for it.
Re:"extensive measures" taken...
on
NVIDIA Breached
·
· Score: 1
My hopes are that it means ensuring anyone on the outside is coming in via 2FA
What difference does it make where you are coming from? Majority of costly threats are inside jobs and or enabled by inside human error... All it takes is one marketing goon to get owned and the castle wall is breached.
The very concept of network security is the most disastrous and perilous idea the security world has ever fabricated. If you want network security make IPSec mandatory across the enterprise everything short of this is worthless masturbation.
and DMZ networks have a proper IDS/IPS in place that is tailored to the division in question
IDS/IPS systems are nothing more than bureaucratic checkboxes completely worthless against actual tailored threats.
i.e. a bunch of point of sale terminals would sound an alarm if one of them decides to start making random connections to a site in Elbonia
If it were that simple then why are you granting the capability of point of sale terminals to make random connections to Elbonia in the first place?
there is an internal detection process so someone trying to brute force an account will make an audit trail and get a curious admin looking at why the events are happening.
If an online brute-force attacks ever succeed you've already failed. Doubtful requisite competence to catch this fact on the back-end even exists within such an organization.
My hopes also include isolation of DMZ boxes so that unless they are intended to communicate with each other, they can't. Isolation between departments would be nice as well.
Isolate those suckers or just replace them with bricks.
Finally, my hopes include having remote access being more of using Citrix or RDP and having the remote machine be more of a dumb terminal, as opposed to an active VPN, making the remote machine a part of the corporate network.
Turtles all the way down.
Of course, my fear is that "extensive measures" will be a domain admin logging on, popping up a command shell, typing in:
dsquery user | dsmod user -mustchpwd yes
and calling it a wrap.
I think this is about right. Attacker compromises domain, hooks pass filter API, make a scary noise and waits for everyone to change their passwords.
I'm hoping nVidia does more of the "hopes" portion.
I'm hoping the entire industry gets off its ass and does something other than continue to waste time, money and resources on pointless layers of worthless security just so they can pencil in a few checkboxes and CYA.
Tried "reflowing" an old IBM Thinkpad with failing GPU socket once.
Tried to be careful and do it right placing aluminum foil around everything that wasn't GPU... used a heat gun and IR thermometer along with...u... umm... ah... instructions pulled off the.....um... Internet.
End result was a number of surface mount chips on the opposite side of the board had melted off of their pads and dropped clear off... mainboard basically a total loss.
Trying was better than nothing as computer was not worth cost of repairing and any replacement board you could source on ebay would have come with same defective design/soldering job.
Loss of Trust: Information provided by Edward Snowden
Trust? What the fuck are you smoking???... The prior US administration LIED and started a goddamn war under completely false pretenses leading to the deaths of hundreds of thousands displacing millions over the course of a decade...not a little privacy invasion or reading love letters...but grand fucking high crimes against humanity. A *DECADE* ago we found out about NSA collection of *ALL* domestic phone records.... As much as I love Ed Snowden there was no trust remaining to lose when he spoke out.
I trust the Internet was insecure and all kinds of TLA's and assorted bad actors were exploiting to the hilt from the very start. Security is our responsibility...nobody else's.
Those are singular examples to the issues I spoke of, there are many, many more. In addition, only a small percentage of data has been released to the public from the "Snowden Cache", if it was all released maybe people like you would finally STFU
The only thing you have enumerated was bullshit about SSL and HSTS which were factually incorrect and demonstrate your lack of knowledge of underlying technology. It shows you can read technical articles without having a firm grasp of fundamentals. The rest is just bloviating about enumeration of unspecified this and that's...you have nothing specific to say.
If anything what Snowden told us is that the systems we *know* are secure really are a PITA even for the NSA to crack...Snowden himself said as much during a hearing he remotely participated in from Russia and in several televised interviews with reporters earlier in the year.
The underlying point remains running around yelling "How can you trust anything"... is not helpful in any way... It spreads FUD and makes no positive contribution.
It is actually very simple. Amazing that people have so much faith in their inherently insecure certificate systems. If you want security then shared secrets are the only way.
Like most things it is in the implementation rather than underlying technology where things fail and people run into trouble. Punting to PSKs has its own set of operational problems which can ultimately be less convenient and more difficult to manage vs proper deployment of PKI.
Or to take it a step further if you want security then OTP pools are the only way... except few actually want it that bad.
What makes you think they haven't broken the encryption, what makes you think they don't have full access to all certificates, what makes you think you can trust anything.
What makes you think doubting everything in the absence of specific affirmative evidence is at all a useful exercise?
I'll point out that SSL is meaningless when the MITM can record it all and decrypt later, or possibly decrypt on the fly.
Decrypting later after you've obtained keys can be defeated by enabling forward secrecy. With most SSL toolkits your looking at a few extra lines of code tops. No rocket science required.
And HSTS is meaningless as well, so don't bother bring up that nugget
The HSTS latch is one small but important piece of the puzzle. It isn't meaningless it just offers limited intrinsic value.
Obviously it remains possible to trick people or launch attacks using convincingly or homographically similar names gleaned from insecure information sources. Not HSTS's fault.
HSTS works if you enter site manually and forget to add 'https' or set a bookmark to reference non-secure version of the site. The way it fails is when you use a search engine over insecure channel and provided the wrong address to the wrong "secure" site by an attacker. GIGO.
I doubt there is any readily available encryption that can protect you at this point.
If one and only one person is convicted, it's "illegal", no matter how many people get away with it.
Are you saying if one court says "x" is illegal and another court disagrees saying same "x" is legal.... illegal determinations are automatically preferred winning out by default?
What are you saying? I don't understand.
If it's so clear from the supreme court that obscenity is legal, why did Paul Little spend 2 years in jail/prison?
The law is so complex and open to human interpretation it is not always feasible to know what is or is not legal a-priori. Lawyers and judges can and often do legitimately disagree. Hence ability for even relatively pedestrian cases to get pushed all the way to the supreme court for final determination.
Unfortunately not every determination of guilt or legality is correct.
Except that both languages and "application architectures" are, so as to speak, both based on usefully constraining the set of valid programs.
Sorry I don't understand what this means. If you design a data schema that can't scale no language selection, amount of clustering, sharding, money or associated BS is going to be of much help... this is just reality.
Only when machines become smart enough to do the designing will this ever change. Computers can do a lot on the margins but ultimately if you want scalability and performance in a non-trivial problem space YOU will have to work for it.
In the long run, though, stuff tends to move into languages, among other things because it allows checking of correctness at the earliest possible moment during development.
What does constraint validation have to do with scalability and concurrency?
In my view presence of domain specific languages throughout data, application and presentation tiers is the source of the platforms power. It's what makes it not suck.
Yes annoying for beginners to have to learn w,x,y and z just to do anything... what is even more annoying is consequences when it comes time to stand up non-trivial systems.
In my view the future of programming will be about the rise of domain specific languages where very little room remains for lies and assumptions generated by glue languages.
1. Nobody "likes" voicemail. It isn't the point. I'm a customer of yours and I call you expecting to speak with you.... I've already wasted my time with your IVR and now your not there... you bet I'm going to bleepin leave a message AND expect callback. Fuck you if you don't like it...perhaps you would enjoy having no customers or being unemployed better.
2. VM is the most efficient way to get spam callers out of your face. They know if they are transferred to voice mail there is no hope of getting a callback so 9 out of 10 times they just hang up and save you the trouble.
What really irks me about our "modern" world is the often stunning lack of ability to effectively communicate. Everything out there is shit...
Telephones used to be better until everyone started using Internet gateways to bypass LD/international rates... between the heavy accents, packet loss and latency your lucky if your able to understand a single word out of any given spoken sentence.
Email would be awesome if it at least tried to be secure and there was at least some vague assurance when you clicked 'send' your message would not be randomly disappeared by a rogue bayesian algorithm no human understands.
Mobile SMS is too slow, unstructured and interrupt driven to be a viable alternative.
What we are left with to fill gaps are one-off piecemeal solutions we must expect to not be common to any given pair of communication partners.... so much for "progress"....
Actively attacking other signals you believe are breaking criminal or civil law in some way should be referred to appropriate authorities to take action. Vigilantism can be fun yet ultimately unproductive... Expecting FCC to bless such behavior does not strike me as a serious proposition.
Open networks with no layer 2 security cannot be "protected" not by lawyers, not by FCC, not by Hotel operators, not by anyone... All who go there are only wasting their time.
If Hotels really wanted to "protect" their guests from evil operators who by the way can exist at any hop they can start by not placing guests at unnecessary risk in the first place.
Hotel lobbying dollars would be much more constructively directed at tech industry for an operationally viable solution.
Only option I can think of that stands any chance of working today is lighting up a virtual SID for each room and handing out WPA2 passwords with room keys valid for duration of your stay.
Shifters, signals, lights, wipers, gas, break, hazards, fogs, steering..etc are designed to be manipulated by tactile feedback alone. Likewise my audio system was selected for its ability to be fully controllable via tactile feedback.
Driving is not a "game".. touch interfaces have no place in a vehicle.
Too often when I hear of "researchers" discovering "flaws" turns out all they are doing is demonstrating an obvious result from commonly known properties of a system.
You mean you can just mount that unencrypted drive, change root password, boot up and have full access to everything? Well jolly geeewiz...
SS7 "flaw" is standard operating procedure for Telco's where only meaningful form of security has always been adult supervision.
Not much different from what happens when one or more "adults" setting up BGP sessions turns out to be an immature little brat.
Only difference at least people know the Internet isn't secure and can plan accordingly by plugging in the E2E security solution of their choice.
Have a smartphone and want to replace standard voice codec with an encrypted one? Sorry that's locked away in the baseband.. access denied son.
Attempts to setup globally trustworthy systems have consistently devolved into jokes. Humanity appears to lack necessary intelligence and integrity to pull it off. The best we can do right now is piecemeal E2E solutions.
- the connection is permanent, multiple request pipe lined trough same connection - The page are by today standard variable sized, headers are vaiable sized - Compression is often used - AES and most symmetric cipher are block ciphe rand rounded
People pointing out all of the ways my response COULD be wrong or if x, y, z countermeasures taken then my scheme is foiled....and and if you used TOR or something then even your IP would be safe... My central goal here is to communicate Joe Biden's point when asked about telephone metadata collection not to nit pick and dot my j's and cross my 0's.
Lets examine some of the responses..
Well just add padding so they won't know... well ok...who is doing that?
Multiple requests encapsulated in an HTTP 1.1 pipeline or futuristic 2.0 scheme... so what? You visit a page and the chatter stops while your reading it and starts up again when you click something else and follow a different link.
There could be dynamic content and that could render it difficult to discern x, y and z... This could be true or not depending on the site.
Compression - I don't get how this is relevant... When NSA/KGB goes to your site to collect baselines wouldn't the data be compressed or not the same as any other visitor?
- AES and most symmetric cipher are block ciphe rand rounded
With AES your looking at a block size of between 16 and 32 bytes.
Insecure shopping cart comments.. If you have a shopping cart on your website it stands to reason you already have an SSL certificate so the question posed regarding value of HTTPS over HTTP is not applicable - otherwise I agree what you enter on a form is probably very safe from prying eyes when using HTTPS vs HTTP.
Random padding for BREACH mitigation... I'll believe there is someone on earth who cared enough to implement this vs simply disabling compression for *dynamic* assets when I see it for myself. Compression overhead for dynamic content was always of questionable ROI as it is.
Slashdot Mirror
I touched OpenSSL once. It was a nightmare. No idea where or how it passed anything as it wasn't at all clear the path that simple things, like certificate checking, were supposed to take.
In the end, I hacked onto it rather than play with it. The documentation was non-existent. The code samples were incomplete and with almost zero explanation of what you were supposed to be checking for and where things COULD go wrong. Hence 90% of the code I see that touches OpenSSL looks exactly like the samples and nothing more.
LOL I agree with you the documentation sucks especially when you have any need to go off the SSL_* rails...yet this is niche + free shit and in that context well in line with a number of open source C APIs or generally what I've come to expect.
There is a separate .c file for every command verb you can possibly type from openssl CLI in the apps folder.
I've seen a number of cut and paste jobbers in various projects where authors obviously had taken no time to understand what they were doing yet this is hardly unique to OpenSSL. This kind of thing exists everywhere even where excellent documentation exists.
All I wanted to do was have two x509 certificates, and check that both were valid and one properly signed the other, as part of a primitive DRM scheme I was toying with. It turned into a nightmare scenario of IMAGINING every possible outcome and specifically coding for each one, rather than anything sensible.
Here is where my experience diverges... yes the API could be better, documentation could exist yet these arguments about APIs also applies to using OpenSSL from CLI. For many it is a bunch of magical incantations most people just cut and paste parameters from examples without having a firm grasp of underlying structure. The problem is lack of trivial abstractions tailored to specific use cases to make specific peoples jobs as easy as possible.
The same concepts apply to iptables or ffmpeg... I just want to block an IP or rip a DVD to mkv.. why do I need to know all of this extraneous BS? Well you don't if you used the proper front end/abstraction API. Most systems I've ever screwed with are this way.
Having taken the time to understand how to manage and check certificates using the OpenSSL API.. it was difficult to find information and understand screwy structures like X509_* vs EVP_PKEY but most of my problems were rooted in lack of knowledge in some specifics about how the technology itself worked even though I've used OpenSSL API and CLI in other contexts for years.
The API has never failed me yet in the sense I found myself having to resort to low level drudgery operating on levels far beneath what was ideal and whenever I needed a callback to tweak how OpenSSL worked one was available to me. Not ideal, but hardly unexpected, nightmare or more than what I expected going in.
All caps has the distinct connotation of trying to ram something down people's throats.
I'm not ready to swallow that Bush told us something he didn't himself believe ("It's not a lie if you believe it" cf. G. Costanza), but if I could do that how is our current WH exempt from:
Caps was only intended as emphasis if you took it to mean something else I apologize.
In my mind the matter is settled. We have interviews with low level intelligence folk, we have downing street memo, we have Rumsfeld memo...that so many separate threads of dubious evidence... evidence known at the time to be strenuous at best paraded before the country and world as solid fact when no serious subject matter expert believed such at the time is no accident. It is impossible to know everything that went on or what people believed or knew what. I've seen enough BS to make up my own mind quite comfortably.
(1) having the IRS agitate against people for one side of political beliefs and not the other
(2) broad, open warrants
(3) ordering the Syrian embassy security to an artificially low level (Paris had more security on deck)
And then call all of these things "phony scandals"?
I think you are using all capital letters because you realize you are in a little over your head here with your claims.
I have never in my life said anything about any of the above topics. Please add signature drone strikes to Obama's list.
Why would anyone want to fix the problem?
DDOS mitigation services make money. DDOS attack services make money. The people who are targets are not going to do anything other than pay someone to help them stay on the air.
There is not even enough interest to take even reasonable and relatively trivial steps to fix DNS (draft-eastlake-dnsext-cookies-05) instead full steam ahead with DNSSEC we don't care about consequences.
BCP38 adds little additional value should the few broken protocols deployed in sufficient quantity to be useful for DDOS are fixed. The chance of that happening over time in the same way SYN cookies happened is in my view more realistic than expecting operators to implement BCP38 with enough coverage and granularity to be useful.
About those botnet armies of millions of unfortunate souls owned by viruses and malware... who wants to fix that? Security companies would go out of business right and left if millions of PCs ceased to get owned on a regular basis overwhelmingly not by exploiting vulnerabilities or viral propagation but by simple social engineering tricking people to run an attachment or download something from a website.
The perverse thread through all of this is total lack of market based incentive to fix anything. The more dysfunctional the network is to use the more people get paid to deal with the consequences and the more institutional pressure exists to retard progress.
It seems to me if you really cared to move the needle following would be necessary.
1. Replace SMTP.
2. Compel advertising networks to stop being complicit in propagation of malware.
3. Add n00b 1337 options when installing operating systems to give users rope commensurate with their needs and abilities.
Separate jails for browsers and downloads by default would help a lot. What isn't helpful is crap like UAC which does nothing to protect users data/environment or prevent system from being coopted for DDOS.
Isolated application model of mobile devices could also be helpful when architected to support rather than exploit end users.
I can't see how employee's SSN's will improve the open source codebase.
Why are SSN's permanent life-long secret codes only the people who represent them should know?
I think in aggregate if everyone's SSN were made public it would prevent a vast sea of morons from relying on them for purposes for which they were neither intended or suitable and everyone would be better for it.
My hopes are that it means ensuring anyone on the outside is coming in via 2FA
What difference does it make where you are coming from? Majority of costly threats are inside jobs and or enabled by inside human error... All it takes is one marketing goon to get owned and the castle wall is breached.
The very concept of network security is the most disastrous and perilous idea the security world has ever fabricated. If you want network security make IPSec mandatory across the enterprise everything short of this is worthless masturbation.
and DMZ networks have a proper IDS/IPS in place that is tailored to the division in question
IDS/IPS systems are nothing more than bureaucratic checkboxes completely worthless against actual tailored threats.
i.e. a bunch of point of sale terminals would sound an alarm if one of them decides to start making random connections to a site in Elbonia
If it were that simple then why are you granting the capability of point of sale terminals to make random connections to Elbonia in the first place?
there is an internal detection process so someone trying to brute force an account will make an audit trail and get a curious admin looking at why the events are happening.
If an online brute-force attacks ever succeed you've already failed. Doubtful requisite competence to catch this fact on the back-end even exists within such an organization.
My hopes also include isolation of DMZ boxes so that unless they are intended to communicate with each other, they can't. Isolation between departments would be nice as well.
Isolate those suckers or just replace them with bricks.
Finally, my hopes include having remote access being more of using Citrix or RDP and having the remote machine be more of a dumb terminal, as opposed to an active VPN, making the remote machine a part of the corporate network.
Turtles all the way down.
Of course, my fear is that "extensive measures" will be a domain admin logging on, popping up a command shell, typing in:
dsquery user | dsmod user -mustchpwd yes
and calling it a wrap.
I think this is about right. Attacker compromises domain, hooks pass filter API, make a scary noise and waits for everyone to change their passwords.
I'm hoping nVidia does more of the "hopes" portion.
I'm hoping the entire industry gets off its ass and does something other than continue to waste time, money and resources on pointless layers of worthless security just so they can pencil in a few checkboxes and CYA.
Tried "reflowing" an old IBM Thinkpad with failing GPU socket once.
Tried to be careful and do it right placing aluminum foil around everything that wasn't GPU... used a heat gun and IR thermometer along with ...u... umm... ah... instructions pulled off the.....um... Internet.
End result was a number of surface mount chips on the opposite side of the board had melted off of their pads and dropped clear off ... mainboard basically a total loss.
Trying was better than nothing as computer was not worth cost of repairing and any replacement board you could source on ebay would have come with same defective design/soldering job.
You are poorly informed.
About?
http://www.nytimes.com/2013/09...
Certificate Authority:
http://en.wikipedia.org/wiki/D...
Old news virtually everyone here knows well.
Loss of Trust:
Information provided by Edward Snowden
Trust? What the fuck are you smoking???... The prior US administration LIED and started a goddamn war under completely false pretenses leading to the deaths of hundreds of thousands displacing millions over the course of a decade...not a little privacy invasion or reading love letters...but grand fucking high crimes against humanity. A *DECADE* ago we found out about NSA collection of *ALL* domestic phone records.... As much as I love Ed Snowden there was no trust remaining to lose when he spoke out.
I trust the Internet was insecure and all kinds of TLA's and assorted bad actors were exploiting to the hilt from the very start. Security is our responsibility...nobody else's.
Those are singular examples to the issues I spoke of, there are many, many more.
In addition, only a small percentage of data has been released to the public from the "Snowden Cache", if it was all released maybe people like you would finally STFU
The only thing you have enumerated was bullshit about SSL and HSTS which were factually incorrect and demonstrate your lack of knowledge of underlying technology. It shows you can read technical articles without having a firm grasp of fundamentals. The rest is just bloviating about enumeration of unspecified this and that's ...you have nothing specific to say.
If anything what Snowden told us is that the systems we *know* are secure really are a PITA even for the NSA to crack...Snowden himself said as much during a hearing he remotely participated in from Russia and in several televised interviews with reporters earlier in the year.
The underlying point remains running around yelling "How can you trust anything" ... is not helpful in any way... It spreads FUD and makes no positive contribution.
It is actually very simple. Amazing that people have so much faith in their inherently insecure certificate systems. If you want security then shared secrets are the only way.
Like most things it is in the implementation rather than underlying technology where things fail and people run into trouble. Punting to PSKs has its own set of operational problems which can ultimately be less convenient and more difficult to manage vs proper deployment of PKI.
Or to take it a step further if you want security then OTP pools are the only way... except few actually want it that bad.
Article talks about VPN being no problem ... surveil 20,000 vpn connections per hour in 2011.
Not surprising given the number of clueless operators still using VPN technology WELL KNOWN to be insecure for going on two decades now.
What makes you think they haven't broken the encryption, what makes you think they don't have full access to all certificates, what makes you think you can trust anything.
What makes you think doubting everything in the absence of specific affirmative evidence is at all a useful exercise?
I'll point out that SSL is meaningless when the MITM can record it all and decrypt later, or possibly decrypt on the fly.
Decrypting later after you've obtained keys can be defeated by enabling forward secrecy. With most SSL toolkits your looking at a few extra lines of code tops. No rocket science required.
And HSTS is meaningless as well, so don't bother bring up that nugget
The HSTS latch is one small but important piece of the puzzle. It isn't meaningless it just offers limited intrinsic value.
Obviously it remains possible to trick people or launch attacks using convincingly or homographically similar names gleaned from insecure information sources. Not HSTS's fault.
HSTS works if you enter site manually and forget to add 'https' or set a bookmark to reference non-secure version of the site. The way it fails is when you use a search engine over insecure channel and provided the wrong address to the wrong "secure" site by an attacker. GIGO.
I doubt there is any readily available encryption that can protect you at this point.
Protect who from what?
If one and only one person is convicted, it's "illegal", no matter how many people get away with it.
Are you saying if one court says "x" is illegal and another court disagrees saying same "x" is legal.... illegal determinations are automatically preferred winning out by default?
What are you saying? I don't understand.
If it's so clear from the supreme court that obscenity is legal, why did Paul Little spend 2 years in jail/prison?
The law is so complex and open to human interpretation it is not always feasible to know what is or is not legal a-priori. Lawyers and judges can and often do legitimately disagree. Hence ability for even relatively pedestrian cases to get pushed all the way to the supreme court for final determination.
Unfortunately not every determination of guilt or legality is correct.
Except that both languages and "application architectures" are, so as to speak, both based on usefully constraining the set of valid programs.
Sorry I don't understand what this means. If you design a data schema that can't scale no language selection, amount of clustering, sharding, money or associated BS is going to be of much help... this is just reality.
Only when machines become smart enough to do the designing will this ever change. Computers can do a lot on the margins but ultimately if you want scalability and performance in a non-trivial problem space YOU will have to work for it.
In the long run, though, stuff tends to move into languages, among other things because it allows checking of correctness at the earliest possible moment during development.
What does constraint validation have to do with scalability and concurrency?
http://www.brainyquote.com/quo...
Wake me up when you have something falsifiable to say.
Why shouldn't a language solve the problem of concurrency and distributed applications?
Because this can only be effectively answered by the application?
Language does not enable non-trivial problems to scale out... application architecture enables this and concurrency is of the same coin.
In my view presence of domain specific languages throughout data, application and presentation tiers is the source of the platforms power. It's what makes it not suck.
Yes annoying for beginners to have to learn w,x,y and z just to do anything... what is even more annoying is consequences when it comes time to stand up non-trivial systems.
In my view the future of programming will be about the rise of domain specific languages where very little room remains for lies and assumptions generated by glue languages.
Not the ones I get. Their auto-thing knows that VM is picking up, so it marks it as a failure, and they call twice a day for months.
Sorry if I gave the wrong impression. My comment was made with assumption of a business environment where calls are answered by IVR / secretary.
When incoming calls go direct to VM there is no pain for caller in having a computer try again forever - your certainly right.
Reality proves you wrong. If obscene speech was NOT illegal, then Paul Little wouldn't have been convicted of obscenity.
OR are you arguing that reality is wrong because it contradicts your opinion?
Cherry picking a specific example to establish your case is an interesting strategy.
If I pointed out a case such as Redrup v NY in which obscenity convictions were overturned by the US supreme court then where does that leave us?
1. Nobody "likes" voicemail. It isn't the point.
I'm a customer of yours and I call you expecting to speak with you.... I've already wasted my time with your IVR and now your not there... you bet I'm going to bleepin leave a message AND expect callback. Fuck you if you don't like it...perhaps you would enjoy having no customers or being unemployed better.
2. VM is the most efficient way to get spam callers out of your face. They know if they are transferred to voice mail there is no hope of getting a callback so 9 out of 10 times they just hang up and save you the trouble.
What really irks me about our "modern" world is the often stunning lack of ability to effectively communicate. Everything out there is shit...
Telephones used to be better until everyone started using Internet gateways to bypass LD/international rates... between the heavy accents, packet loss and latency your lucky if your able to understand a single word out of any given spoken sentence.
Email would be awesome if it at least tried to be secure and there was at least some vague assurance when you clicked 'send' your message would not be randomly disappeared by a rogue bayesian algorithm no human understands.
Mobile SMS is too slow, unstructured and interrupt driven to be a viable alternative.
What we are left with to fill gaps are one-off piecemeal solutions we must expect to not be common to any given pair of communication partners.... so much for "progress"....
Actively attacking other signals you believe are breaking criminal or civil law in some way should be referred to appropriate authorities to take action. Vigilantism can be fun yet ultimately unproductive... Expecting FCC to bless such behavior does not strike me as a serious proposition.
Open networks with no layer 2 security cannot be "protected" not by lawyers, not by FCC, not by Hotel operators, not by anyone... All who go there are only wasting their time.
If Hotels really wanted to "protect" their guests from evil operators who by the way can exist at any hop they can start by not placing guests at unnecessary risk in the first place.
Hotel lobbying dollars would be much more constructively directed at tech industry for an operationally viable solution.
Only option I can think of that stands any chance of working today is lighting up a virtual SID for each room and handing out WPA2 passwords with room keys valid for duration of your stay.
Shifters, signals, lights, wipers, gas, break, hazards, fogs, steering..etc are designed to be manipulated by tactile feedback alone. Likewise my audio system was selected for its ability to be fully controllable via tactile feedback.
Driving is not a "game" .. touch interfaces have no place in a vehicle.
Too often when I hear of "researchers" discovering "flaws" turns out all they are doing is demonstrating an obvious result from commonly known properties of a system.
You mean you can just mount that unencrypted drive, change root password, boot up and have full access to everything? Well jolly geeewiz...
SS7 "flaw" is standard operating procedure for Telco's where only meaningful form of security has always been adult supervision.
Not much different from what happens when one or more "adults" setting up BGP sessions turns out to be an immature little brat.
Only difference at least people know the Internet isn't secure and can plan accordingly by plugging in the E2E security solution of their choice.
Have a smartphone and want to replace standard voice codec with an encrypted one? Sorry that's locked away in the baseband.. access denied son.
Attempts to setup globally trustworthy systems have consistently devolved into jokes. Humanity appears to lack necessary intelligence and integrity to pull it off. The best we can do right now is piecemeal E2E solutions.
You forgot that:
- the connection is permanent, multiple request pipe lined trough same connection
- The page are by today standard variable sized, headers are vaiable sized
- Compression is often used
- AES and most symmetric cipher are block ciphe rand rounded
People pointing out all of the ways my response COULD be wrong or if x, y, z countermeasures taken then my scheme is foiled....and and if you used TOR or something then even your IP would be safe... My central goal here is to communicate Joe Biden's point when asked about telephone metadata collection not to nit pick and dot my j's and cross my 0's.
Lets examine some of the responses..
Well just add padding so they won't know... well ok...who is doing that?
Multiple requests encapsulated in an HTTP 1.1 pipeline or futuristic 2.0 scheme... so what? You visit a page and the chatter stops while your reading it and starts up again when you click something else and follow a different link.
There could be dynamic content and that could render it difficult to discern x, y and z... This could be true or not depending on the site.
Compression - I don't get how this is relevant... When NSA/KGB goes to your site to collect baselines wouldn't the data be compressed or not the same as any other visitor?
- AES and most symmetric cipher are block ciphe rand rounded
With AES your looking at a block size of between 16 and 32 bytes.
Insecure shopping cart comments.. If you have a shopping cart on your website it stands to reason you already have an SSL certificate so the question posed regarding value of HTTPS over HTTP is not applicable - otherwise I agree what you enter on a form is probably very safe from prying eyes when using HTTPS vs HTTP.
Random padding for BREACH mitigation... I'll believe there is someone on earth who cared enough to implement this vs simply disabling compression for *dynamic* assets when I see it for myself. Compression overhead for dynamic content was always of questionable ROI as it is.
We're all holding our collective breath waiting to hear your practical, commercially and technically feasible alternative.
The proper technical solution is to bind encryption with a secure user authentication protocol.
Dump the certs in the trash where they belong and use TLS-SRP.
Technology is readily available and easy to implement.
Seems only thing this industry is capable of producing these days is creepy stalker gadgets.