I saw those slides. There were 17 levels of #ifdefs in the code.
Wouldn't surprise me if people commenting on hyperbole have never actually seen the source code to OpenSSL or any other open source library. They are all universally littered with ifdefs and compatibility layers from the dawn of civilization with entire suites of meta-programs (e.g. autotools) devoted to making it all work.
When managed properly these things are a non-issue.
seriously pumping openssl full of cash at this point is like buying new deck chairs for the titanic.
It is great to see interest in improving OpenSSL yet bug fixes and deletion of compatibility layers in my opinion is in much the same category as purchase of new deck chairs.
If "we" were serious we would re-architect it from scratch to be secure by design... endeavor in which nobody is currently publically known to be engaged. I hope one or both of the teams seriously considers it. I also hope "dino dung" bravado is replaced with realization everyone is on the same side.
The issue that I find, is that OpenSSL is the only Open Source Player out there. Much like File Systems, we really should have at least a few popular choices, which are interchangeable. So if there is a security problem with one we can switch to an other one.
Several SSL implementations support the OpenSSL API including GnuTLS (open source)
NSS is also open source with shims available to help those porting from OpenSSL.
Having never used them I can't vouch for how useful they are in the real world... assume out of total ignorance they are worthless for anything but the basic SSL_* operations.
The whole security model is broken. How many CAs does your browser come with these days? Do you even know? How do you know they haven't already turned over their CA signing keys to 7 different governments?
There's no way to "fix" openssl. The entire thing is predicated on a false premise.
Nothing in OpenSSL forces you to trust any CA's you don't want to trust. Heck you don't even have to use certificates at all (TLS-PSK, TLS-SRP)
I think it is a mistake to confuse deployment failures with implementation failures with specification failure.. while there are often linkages between these things it is hard to accept that proliferation of hundreds of CA's all with overlapping global scope is anything but a deployment failure.
That is far, far, far out of scope for a standards discussion. That is an issue for activists to take up, not for the HTTP 2.0 discussion.
Your the one who brought up the idea consumers "do not care" as reason B) for dismissal of PHK's privacy concern.
None of what you describe is really an issue for HTTP to be solving. You could argue that cookies have to go, but they fulfill functions today
How many times do I have to repeat myself specifically re-stating my position with regards to cookies before this strawman factory is shuttered?
I really dont get how a discussion on a transport protocol is the proper place for political or content discussions
While formatting of bits have no political implications use of opportunistic encryption is entirely a political matter as is the nature of information exchanged between parties.
Protocols not designed to account for realities of political, social and financial realms are likely to either be harmful or worthless in the real world they are deployed into. Any yahoo can design a state machine and protocol fields.... it requires much thoughtfulness and skill to design something that benefits everyone.
How is the Auth1 scheme described above susceptible to offline dictionary attacks?
The supposed MITM would attempt to offline brute force the Passhash as they now know the inputs to the HMAC, and they know the correct Auth1 value?
Yes, Nonce1 + Nonce2 are pulled off wire by attacker.
Attacker keeps trying HMAC(bruteforce,Nonce1 + Nonce2) until it can successfully decode the "mother fucking stream cipher"
These CHAP digest schemes all have the same problem no matter what algorithm you use or how you jiggle parameters. Zero knowledge proof of possession is the future of password authentication.
Let me get this straight: You think it a good idea to attempt to subvert a standard to make it incredibly difficult for the biggest users of said standard to use it?
I agree only with the sentiment current state of affairs sucks. Although not stated earlier I personally disagree with idea of removing cookies.
Reread what I said in context. I am not arguing for or against... only the reality that very little power rests in the hands of protocol designers.
B) the primary consumers do not care
Do they have any idea what is going on? Are they properly informed?
If you're visiting websites with trackers, and youre upset that they are tracking you, I have bad news: Nothing will change the fact that the webhost has logs of your visit, and no standard can fix that.
Personally I assume every site I visit to log information about my visit the same way every person I interact with in public remembers conversations or observes me walking down the street. I have no problem with this.
Bumping into someone in public is quite a different matter from following them around everywhere they go. Stalking is illegal in the united states and most countries.
I consider third parties which sit in the middle and collect track, aggregate and sell data on virtually every site I visit online to be fundamentally no different than stalking. I find this unacceptable and refuse to accept this behavior as legitimate or legal and have taken measures to deny these firms the capability to track me.
This is why we should just use HTTP Auth, or update it so that we can. I mean, we already have pre-shared secrets with all the places we need secure.
Client sends: UserName, Nonce1 Server sends: Nonce2
Both perform: Auth1 = HMAC( Passhash, Nonce1 + Nonce2 ); Where + is concatenation and Passhash is PBKDF2 or keystretching, etc. of the user password. The server can store the hashed version. Hash because: Fuck length and special chars limits.
All of these crappy schemes are vulnerable to offline dictionary attack. We need to step away from our addiction to the CHAP garbage and move to zero-knowledge systems.
This shit really isn't rocket science folks. The truth is that the IETF is a bunch of morons or malicious bastards. Take your pick. Either way they've actively worked to make sure no connection on the web can be trusted not to have a potential MITM via CA system. Anything is better than that. The window for PW exchange is so small and if the MITM missed it or erased that, or the PW was exchanged out of band then they couldn't ever MITM your connection.
Last I checked the IETF isn't the one refusing to apply TLS-SRP patches sitting in their ticket systems. They did their job in 2007 (RFC5054)
It is the browser vendors sleeping on their feet. Support is included in most mainstream TLS toolkits, Apache and CURL already support it.
NSA proof is possible unless NSA includes goons armed with $5 wrenches.
The whole point here is not to make the system undefeatable, just to increase the cost of breaking it, just like your door lock isn't perfect, but still useful.
If you can't view traffic then traffic is safe from you therefore it is not necessary to encrypt traffic.
If you can view traffic then you have everything necessary to own that traffic.. TCP initial sequence number and fast pipe is all you need... nobody is doing any of the filtering necessary to prevent source address spoofing so these attacks are trivial.
If your data is going through a "great firewall", CGN (everyone using a cellular network) or other bump in the wire there is no reason not to expect opportunistic encryption to be MITMd in realtime and in bulk.
it would require the NSA to man-in-the-middle every single connection if it wants to keep its pervasive monitoring.
So everyone in US is safe from NSA bulk collection of websites they visit except bulk collection of IP layer headers, certificate identities sent in the clear during TLS handshake and the zillions of US corporations engaged in cross site stalking compelled to hand over "any tangible thing".
What is the opportunity cost of an encryption solution which solves nothing? What resources and demand are no longer available to be applied to a solution with teeth?
How do you explain to the user well their data might be encrypted yet their data is not protected since it is not trusted? I can see the eyes rolling and roar of millions of swooshes... All people know is "encrypted" and this means "safe"... I see nothing good coming from introduction of this technical doublespeak.
Does HTTP 2.0 implement any latching or fingerprinting that could be useful to retroactively detect compromise of security? Do they even try?
Back in the day you actually had to pick up the phone, speak with someone and provide corporate documentation. Now you purchase certs from a computer in an 100% automated process. Completely "just bits" worthless.
It's in the security of the private key, some validation in extended verification certs
Extended verification is a foolish scam to enrich CAs. Users hardly understand what the padlock icon means in URL bar after being intentionally inundated with fake padlock gifs and "we're secure" believe what we say assertions littering every online commerce and banking site on the planet.
I think following demonstrates reality participants in standards organizations are constrained by the market and while they do yield some power it must be exercised with extreme care and creativity to have any effect past L7.
As much as many people would like to get rid of Cookies -- something you've proposed many times -- doing it in this effort would be counter-productive.
Counter-productive for *who* Mark ?
Counter-productive for FaceBook, Google, Microsoft, NSA and the other mastodons who use cookies and other mistakes in HTTP (ie: user-agent) to deconstruct our personal identities, across the entire web ?
Even with "SSL/TLS everywhere", all those small blue 'f' icons will still tell FaceBook all about what websites you have visited.
The "don't track" fiasco has shown conclusively, that there is never going to be a good-faith attempt by these mastodons to improve personal privacy: It's against their business model.
And because this WG is 100% beholden to the privacy abusers and gives not a single shit for the privacy abused, fixing the problems would be "counter-productive".
If we cared about human rights, and privacy, being "counter-productive" for the privacy-abusing mastodons would be one of our primary goals.
It is impossible for me to disagree with this. Have several dozen tracking/market intelligence/stat gathering firms blackholed in DNS where creative use of DNS to implement tracking cookies do not work. I count on the fact they are all much too lazy to care about a few people screwing with DNS or operating browser privacy plugins.
I'm personally creeped out by hoards of stalkers following me everywhere I go...yet I see the same mistakes play out again and again... people looking to solve problems without consideration of second order effects of their solutions.
You could technically do something about those army of stalker creeps... yet this may just force them underground, pulling same data thru backchannels established directly with site - rather than a cut and paste javascript job it would likely turn into module loaded into backend stack with no visibility to the end user or ability to control.
While this would certainly work wonders for site performance and bandwidth usage... those limited feedback channels we did have for the stalked to watch the stalker are denied. On flipside of the ledger not collecting direct proof of access could disrupt some stalker creeps business models.
I think emotional half-assed reaction to NSA with established ability to "QUANTUM INSERT" ultimately encourages locally optimal solution having effect of affording no actual safety or privacy to anyone.
Not only does opportunistic encryption provide a false sense of security to the vast majority of people who simply do not understand relationship between encryption and trust such deceptions effectively work to relieve pressure on need for a real solution.. which I assume looks more like DANE and associated implosion of SSL CA market.
My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.
you can't release code whose intent or effect is to infringe on someone else's rights.
Affect of '-f' option in unix ping utility could very well infringe on my right to maintain a presence on the Internet. Does this mean coders of flag need to be carted off to jail or sued for untold trillions?
Act of invoking lawsuits to solve technical deficiencies and lack of willingness to tolerate those who piss you off significantly lowers my opinion of Blizzard.
Under your perverse logic, anti-virus software would be "unconstitutional censorship."
There seems to be plenty of perverse logic to go around.
Also, "modern" allocators often try to have the memory space after it not be valid so they cause exceptions on reads beyond the buffer
Everything not in process address space is invalid. Oversized "block" allocations meted out internally within process heap is actually contiguous.. this is how binning works.
buffer and put a canary at the end of the allocation and warn if it disappears so buffer overflows also get spotted even if they are tiny
Obviously no help WRT heartbleed.
I'm neither supporting or defending in aggregate merits of OpenSSL memory management scheme.
My objection is limited to these nonsense assertions usage of operating system allocator would have meaningfully mitigated heartbleed vulnerability.
The consensus among security experts seems to be that TLS (the protocol itself) sucks, OpenSSL sucks, GnuTLS sucks, NSS sucks, and TLS has horrible compatibility problems between implementations.
Blah blah blah... sucks...... blah is shit... blah is horrible... ad nauseam.
Too easy to invoke. Concurrently too difficult in typical context free usage to falsify... saying "x sucks"... just... sucks...
To help speed it up, donate $$ so that they can bring in more programmers.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.
Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.
Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.
OpenSSL uses their own funky versions of malloc and free which pre-allocate large chunks of memory from the OS (as in, many pages), then implement their own in-process memory management on top of that. They don't free those pages back to the OS either, at least not anywhere near as soon as a sane memory manager would.
Common for modern allocators to snatch more than immediately requested and hang on to freed memory longer than necessary. This is the basis by which optimized/fragmentation avoidant allocators are able to function.
Has anyone looked at source code for any staple unix program or library?
These things are universally teeming in preprocessor defs for every platform you could imagine. Autotools enshrines defacto standard operating procedures with entire header files, replacement libraries, #ifdef's and funky meta programs for virtually every function and historical errata imaginable.
Existence of these things in and of themselves is not a problem if managed properly. When I see commit comments full of snark and rage while concurrently support for leading platforms and necessary features are dropped this is unfortunate when I can't use it... even if LibreSSL was 100x better in every way... it won't even compile so no point.
Does it matter if some random citizen is killed by a criminal or terrorist? They are dead by malevolent hands either way.
We have a situation where a 9/11 number of people are killing each other in a more or less statistically predictable fashion every quarter decade over decade. It happened this quarter, it will happen the next and the one after that...yet nobody at NSA seems to be talking or otherwise giving two shits about that.
I think we should be looking at ALL risks and reallocate funds away from NSA,TSA,CIA military industrial machine toward endeavors which in the real world stand most chance of providing highest ROIs based on objective evidence rather than current environment of allocation based on fear and politics.
After all list of attacks actually prevented by these agencies appears quite pathetic commensurate with expenditures.
Quite stunning not one of these goons have been able to articulate how collection of everyone's phone records is necessary to conduct a specific authorized investigation while continuing to publically seek retroactive authorization.
The "intelligence community" breaks the law and knowingly enabled wars directly responsible for the deaths of hundreds of thousands based on information they knew at the time to be factually deficient. "Traitors" seems too kind.
I would rather start above layer 4 with DNS, SNMP, NTP, SIP and other niche UDP based offenders giving away insane DOS amplification to any script kiddie in the world who wants to cause havoc. These are relatively trivial problems to fix from protocol design perspective and provide highest returns on investment even after factoring in lag time to get changes propagated thru a good enough percentage of worlds network stacks.
They were somehow designed on the assumption that all participating machines are well behaved good citizens. In practice this ain't happening (see SYN flood for example, there are "mitigation" measure but none is a definitive "fix").
SYN flood has never offered an attacker amplification..it was limited to a cheesy device to overload host TCP implementations. Cookies have since been universally deployed rendering these attacks useless. Today they are only useful for covert signaling and masking source of non-amplified attack... More importantly these things only work at all because operators are lazy and refuse to implement Ingress filtering. It isn't IP's fault.
These need to be replaced with something that would be resistant to mischief by design.
I'm all ears... what do you propose?
Personally I think the premise is invalid. All the network need do is deliver packets with some degree of probability of being delivered. I think it is architecturally correct to leave the edge to sort out how to conduct business in in a mischief avoidant manner.
Otherwise as far as I am aware the only way to stop "mischief" is to turn the Internet into a trusted network. A trusted network is not a free and open network...neither is it particularly practical as we have seen again and again the demonstrated futility of managing planet scale trust anchors.
If ever there was an example of the road to hell being paved with good intentions this type of "secure the Internet" thinking I assert fits that bill.
I think our time is better spent looking above IP layer to fix what is most broke and that which causes most actual damage to actual users. (e.g. SMTP)
Today we have quad core multi-ghz CPUs with gigabytes of memory and 1080 displays. Having installed Linux from floppies on hardware orders of magnitude less capable is it now really too much to ask to have UI execute from a real non-nerf'd operating system?
Why can't I compile and run whatever software that will run on desktop on my phone?
And the implementation is 100%? Nope. With Java, though, I get everything Java has to offer, anywhere Java is available. Maybe platform consistency isn't important to you, but it matters to some people.
Google's implementation of Java is not 100% java either.
Slashdot Mirror
I saw those slides. There were 17 levels of #ifdefs in the code.
Wouldn't surprise me if people commenting on hyperbole have never actually seen the source code to OpenSSL or any other open source library. They are all universally littered with ifdefs and compatibility layers from the dawn of civilization with entire suites of meta-programs (e.g. autotools) devoted to making it all work.
When managed properly these things are a non-issue.
seriously pumping openssl full of cash at this point is like buying new deck chairs for the titanic.
It is great to see interest in improving OpenSSL yet bug fixes and deletion of compatibility layers in my opinion is in much the same category as purchase of new deck chairs.
If "we" were serious we would re-architect it from scratch to be secure by design... endeavor in which nobody is currently publically known to be engaged. I hope one or both of the teams seriously considers it. I also hope "dino dung" bravado is replaced with realization everyone is on the same side.
The issue that I find, is that OpenSSL is the only Open Source Player out there.
Much like File Systems, we really should have at least a few popular choices, which are interchangeable. So if there is a security problem with one we can switch to an other one.
Several SSL implementations support the OpenSSL API including GnuTLS (open source)
NSS is also open source with shims available to help those porting from OpenSSL.
Having never used them I can't vouch for how useful they are in the real world... assume out of total ignorance they are worthless for anything but the basic SSL_* operations.
The whole security model is broken. How many CAs does your browser come with these days? Do you even know? How do you know they haven't already turned over their CA signing keys to 7 different governments?
There's no way to "fix" openssl. The entire thing is predicated on a false premise.
Nothing in OpenSSL forces you to trust any CA's you don't want to trust. Heck you don't even have to use certificates at all (TLS-PSK, TLS-SRP)
I think it is a mistake to confuse deployment failures with implementation failures with specification failure.. while there are often linkages between these things it is hard to accept that proliferation of hundreds of CA's all with overlapping global scope is anything but a deployment failure.
That is far, far, far out of scope for a standards discussion. That is an issue for activists to take up, not for the HTTP 2.0 discussion.
Your the one who brought up the idea consumers "do not care" as reason B) for dismissal of PHK's privacy concern.
None of what you describe is really an issue for HTTP to be solving. You could argue that cookies have to go, but they fulfill functions today
How many times do I have to repeat myself specifically re-stating my position with regards to cookies before this strawman factory is shuttered?
I really dont get how a discussion on a transport protocol is the proper place for political or content discussions
While formatting of bits have no political implications use of opportunistic encryption is entirely a political matter as is the nature of information exchanged between parties.
Protocols not designed to account for realities of political, social and financial realms are likely to either be harmful or worthless in the real world they are deployed into. Any yahoo can design a state machine and protocol fields.... it requires much thoughtfulness and skill to design something that benefits everyone.
How is the Auth1 scheme described above susceptible to offline dictionary attacks?
The supposed MITM would attempt to offline brute force the Passhash as they now know the inputs to the HMAC, and they know the correct Auth1 value?
Yes, Nonce1 + Nonce2 are pulled off wire by attacker.
Attacker keeps trying HMAC(bruteforce,Nonce1 + Nonce2) until it can successfully decode the "mother fucking stream cipher"
These CHAP digest schemes all have the same problem no matter what algorithm you use or how you jiggle parameters. Zero knowledge proof of possession is the future of password authentication.
Let me get this straight: You think it a good idea to attempt to subvert a standard to make it incredibly difficult for the biggest users of said standard to use it?
I agree only with the sentiment current state of affairs sucks. Although not stated earlier I personally disagree with idea of removing cookies.
Reread what I said in context. I am not arguing for or against ... only the reality that very little power rests in the hands of protocol designers.
B) the primary consumers do not care
Do they have any idea what is going on? Are they properly informed?
If you're visiting websites with trackers, and youre upset that they are tracking you, I have bad news: Nothing will change the fact that the webhost has logs of your visit, and no standard can fix that.
Personally I assume every site I visit to log information about my visit the same way every person I interact with in public remembers conversations or observes me walking down the street. I have no problem with this.
Bumping into someone in public is quite a different matter from following them around everywhere they go. Stalking is illegal in the united states and most countries.
I consider third parties which sit in the middle and collect track, aggregate and sell data on virtually every site I visit online to be fundamentally no different than stalking. I find this unacceptable and refuse to accept this behavior as legitimate or legal and have taken measures to deny these firms the capability to track me.
This is why we should just use HTTP Auth, or update it so that we can. I mean, we already have pre-shared secrets with all the places we need secure.
Client sends: UserName, Nonce1
Server sends: Nonce2
Both perform: Auth1 = HMAC( Passhash, Nonce1 + Nonce2 ); Where + is concatenation and Passhash is PBKDF2 or keystretching, etc. of the user password. The server can store the hashed version. Hash because: Fuck length and special chars limits.
All of these crappy schemes are vulnerable to offline dictionary attack. We need to step away from our addiction to the CHAP garbage and move to zero-knowledge systems.
This shit really isn't rocket science folks. The truth is that the IETF is a bunch of morons or malicious bastards. Take your pick. Either way they've actively worked to make sure no connection on the web can be trusted not to have a potential MITM via CA system. Anything is better than that. The window for PW exchange is so small and if the MITM missed it or erased that, or the PW was exchanged out of band then they couldn't ever MITM your connection.
Last I checked the IETF isn't the one refusing to apply TLS-SRP patches sitting in their ticket systems. They did their job in 2007 (RFC5054)
It is the browser vendors sleeping on their feet. Support is included in most mainstream TLS toolkits, Apache and CURL already support it.
Nothing is NSA-proof,
NSA proof is possible unless NSA includes goons armed with $5 wrenches.
The whole point here is not to make the system undefeatable, just to increase the cost of breaking it, just like your door lock isn't perfect, but still useful.
If you can't view traffic then traffic is safe from you therefore it is not necessary to encrypt traffic.
If you can view traffic then you have everything necessary to own that traffic.. TCP initial sequence number and fast pipe is all you need... nobody is doing any of the filtering necessary to prevent source address spoofing so these attacks are trivial.
If your data is going through a "great firewall", CGN (everyone using a cellular network) or other bump in the wire there is no reason not to expect opportunistic encryption to be MITMd in realtime and in bulk.
it would require the NSA to man-in-the-middle every single connection if it wants to keep its pervasive monitoring.
So everyone in US is safe from NSA bulk collection of websites they visit except bulk collection of IP layer headers, certificate identities sent in the clear during TLS handshake and the zillions of US corporations engaged in cross site stalking compelled to hand over "any tangible thing".
What is the opportunity cost of an encryption solution which solves nothing? What resources and demand are no longer available to be applied to a solution with teeth?
How do you explain to the user well their data might be encrypted yet their data is not protected since it is not trusted? I can see the eyes rolling and roar of millions of swooshes... All people know is "encrypted" and this means "safe" ... I see nothing good coming from introduction of this technical doublespeak.
Does HTTP 2.0 implement any latching or fingerprinting that could be useful to retroactively detect compromise of security? Do they even try?
The cost of SSL certificates is not in the bits.
Back in the day you actually had to pick up the phone, speak with someone and provide corporate documentation. Now you purchase certs from a computer in an 100% automated process. Completely "just bits" worthless.
It's in the security of the private key, some validation in extended verification certs
Extended verification is a foolish scam to enrich CAs. Users hardly understand what the padlock icon means in URL bar after being intentionally inundated with fake padlock gifs and "we're secure" believe what we say assertions littering every online commerce and banking site on the planet.
I think following demonstrates reality participants in standards organizations are constrained by the market and while they do yield some power it must be exercised with extreme care and creativity to have any effect past L7.
As much as many people would like to get rid of Cookies -- something
you've proposed many times -- doing it in this effort would be counter-productive.
Counter-productive for *who* Mark ?
Counter-productive for FaceBook, Google, Microsoft, NSA and the other mastodons who use cookies and other mistakes in HTTP
(ie: user-agent) to deconstruct our personal identities, across the entire web ?
Even with "SSL/TLS everywhere", all those small blue 'f' icons will still tell FaceBook all about what websites you have visited.
The "don't track" fiasco has shown conclusively, that there is never going to be a good-faith attempt by these mastodons to improve personal privacy: It's against their business model.
And because this WG is 100% beholden to the privacy abusers and gives not a single shit for the privacy abused, fixing the problems would be "counter-productive".
If we cared about human rights, and privacy, being "counter-productive" for the privacy-abusing mastodons would be one of our primary goals.
It is impossible for me to disagree with this. Have several dozen tracking/market intelligence/stat gathering firms blackholed in DNS where creative use of DNS to implement tracking cookies do not work. I count on the fact they are all much too lazy to care about a few people screwing with DNS or operating browser privacy plugins.
I'm personally creeped out by hoards of stalkers following me everywhere I go...yet I see the same mistakes play out again and again... people looking to solve problems without consideration of second order effects of their solutions.
You could technically do something about those army of stalker creeps ... yet this may just force them underground, pulling same data thru backchannels established directly with site - rather than a cut and paste javascript job it would likely turn into module loaded into backend stack with no visibility to the end user or ability to control.
While this would certainly work wonders for site performance and bandwidth usage... those limited feedback channels we did have for the stalked to watch the stalker are denied. On flipside of the ledger not collecting direct proof of access could disrupt some stalker creeps business models.
I think emotional half-assed reaction to NSA with established ability to "QUANTUM INSERT" ultimately encourages locally optimal solution having effect of affording no actual safety or privacy to anyone.
Not only does opportunistic encryption provide a false sense of security to the vast majority of people who simply do not understand relationship between encryption and trust such deceptions effectively work to relieve pressure on need for a real solution.. which I assume looks more like DANE and associated implosion of SSL CA market.
My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.
Except was always lost, having no sense of up and down has scarred me for life.
So bring on a modern GPU powered rift version.. always assumed someone would go there and I would buy it.
you can't release code whose intent or effect is to infringe on someone else's rights.
Affect of '-f' option in unix ping utility could very well infringe on my right to maintain a presence on the Internet. Does this mean coders of flag need to be carted off to jail or sued for untold trillions?
Act of invoking lawsuits to solve technical deficiencies and lack of willingness to tolerate those who piss you off significantly lowers my opinion of Blizzard.
Under your perverse logic, anti-virus software would be "unconstitutional censorship."
There seems to be plenty of perverse logic to go around.
It's cheating,
Creating software is not cheating. Those who use software tools as means to gain unfair advantage are the ones engaged in cheating.
My first thought was 3d printer. Imagine deposing one atom tick layers of any element in any shape. eg; The Star Trek synthesiser.
But that wont happen because they'll ban the thing over irrational fear before the technology reach the point it can print a cup of earl grey.
This technology is self banning thanks to E=MC^2. How many cups of earl grey do you think you can pour out of a single warp core?
Also, "modern" allocators often try to have the memory space after it not be valid so they cause exceptions on reads beyond the buffer
Everything not in process address space is invalid. Oversized "block" allocations meted out internally within process heap is actually contiguous.. this is how binning works.
buffer and put a canary at the end of the allocation and warn if it disappears so buffer overflows also get spotted even if they are tiny
Obviously no help WRT heartbleed.
I'm neither supporting or defending in aggregate merits of OpenSSL memory management scheme.
My objection is limited to these nonsense assertions usage of operating system allocator would have meaningfully mitigated heartbleed vulnerability.
The consensus among security experts seems to be that TLS (the protocol itself) sucks, OpenSSL sucks, GnuTLS sucks, NSS sucks, and TLS has horrible compatibility problems between implementations.
Blah blah blah ... sucks ... ... blah is shit ... blah is horrible... ad nauseam.
Too easy to invoke. Concurrently too difficult in typical context free usage to falsify... saying "x sucks" ... just ... sucks...
To help speed it up, donate $$ so that they can bring in more programmers.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.
Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.
Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.
OpenSSL uses their own funky versions of malloc and free which pre-allocate large chunks of memory from the OS (as in, many pages), then implement their own in-process memory management on top of that. They don't free those pages back to the OS either, at least not anywhere near as soon as a sane memory manager would.
Common for modern allocators to snatch more than immediately requested and hang on to freed memory longer than necessary. This is the basis by which optimized/fragmentation avoidant allocators are able to function.
Has anyone looked at source code for any staple unix program or library?
These things are universally teeming in preprocessor defs for every platform you could imagine. Autotools enshrines defacto standard operating procedures with entire header files, replacement libraries, #ifdef's and funky meta programs for virtually every function and historical errata imaginable.
Existence of these things in and of themselves is not a problem if managed properly. When I see commit comments full of snark and rage while concurrently support for leading platforms and necessary features are dropped this is unfortunate when I can't use it... even if LibreSSL was 100x better in every way... it won't even compile so no point.
Does it matter if some random citizen is killed by a criminal or terrorist? They are dead by malevolent hands either way.
We have a situation where a 9/11 number of people are killing each other in a more or less statistically predictable fashion every quarter decade over decade. It happened this quarter, it will happen the next and the one after that...yet nobody at NSA seems to be talking or otherwise giving two shits about that.
I think we should be looking at ALL risks and reallocate funds away from NSA,TSA,CIA military industrial machine toward endeavors which in the real world stand most chance of providing highest ROIs based on objective evidence rather than current environment of allocation based on fear and politics.
After all list of attacks actually prevented by these agencies appears quite pathetic commensurate with expenditures.
Quite stunning not one of these goons have been able to articulate how collection of everyone's phone records is necessary to conduct a specific authorized investigation while continuing to publically seek retroactive authorization.
The "intelligence community" breaks the law and knowingly enabled wars directly responsible for the deaths of hundreds of thousands based on information they knew at the time to be factually deficient. "Traitors" seems too kind.
Filemaker Pro, not free, but low entry level, easy to use.
And complete shit. Keep away at all costs.
How about starting with TCP & UDP?
I would rather start above layer 4 with DNS, SNMP, NTP, SIP and other niche UDP based offenders giving away insane DOS amplification to any script kiddie in the world who wants to cause havoc. These are relatively trivial problems to fix from protocol design perspective and provide highest returns on investment even after factoring in lag time to get changes propagated thru a good enough percentage of worlds network stacks.
They were somehow designed on the assumption that all participating machines are well behaved good citizens. In practice this ain't
happening (see SYN flood for example, there are "mitigation" measure but none is a definitive "fix").
SYN flood has never offered an attacker amplification..it was limited to a cheesy device to overload host TCP implementations. Cookies have since been universally deployed rendering these attacks useless. Today they are only useful for covert signaling and masking source of non-amplified attack... More importantly these things only work at all because operators are lazy and refuse to implement Ingress filtering. It isn't IP's fault.
These need to be replaced with something that would be resistant to mischief by design.
I'm all ears ... what do you propose?
Personally I think the premise is invalid. All the network need do is deliver packets with some degree of probability of being delivered. I think it is architecturally correct to leave the edge to sort out how to conduct business in in a mischief avoidant manner.
Otherwise as far as I am aware the only way to stop "mischief" is to turn the Internet into a trusted network. A trusted network is not a free and open network...neither is it particularly practical as we have seen again and again the demonstrated futility of managing planet scale trust anchors.
If ever there was an example of the road to hell being paved with good intentions this type of "secure the Internet" thinking I assert fits that bill.
I think our time is better spent looking above IP layer to fix what is most broke and that which causes most actual damage to actual users. (e.g. SMTP)
Today we have quad core multi-ghz CPUs with gigabytes of memory and 1080 displays. Having installed Linux from floppies on hardware orders of magnitude less capable is it now really too much to ask to have UI execute from a real non-nerf'd operating system?
Why can't I compile and run whatever software that will run on desktop on my phone?
And the implementation is 100%? Nope. With Java, though, I get everything Java has to offer, anywhere Java is available. Maybe platform consistency isn't important to you, but it matters to some people.
Google's implementation of Java is not 100% java either.