Federal officials have anonymously granted immunity to all who confess here (No Anonymous Cowards!) to drunken driving, porn viewing, shoplifting, debauchery, and hacking.
Speaking of hacking... have you ever heard the disks rumbling on your workstation and wonder to yourself WTF was THAT all about? It can be especially unsettling when all disk activity stops the instant you move your mouse to look into what all was going on.
Afraid of having been hax0rd looked into it using standard sysinternals goodness and cought Microsofts CEIP red-handed systematically alphabetically scanning thru folders and files on my computer on a separate data volume from the OS even while CEIP had been completely disabled in action center from day one. The task history clearly shows minutes of runtime activity (Why would it ever need to do anything if it were disabled?) it even logged suspension of itself in reaction to my mouse movements to wake from idle. To confirm and gather data I waited for the 10 minute idle period to record system calls made while it resumed scanning the volume to completion right from where it left off twice previously.
All CEIP tasks have been subsequently disabled from task scheduler.
What I find impossible to comprehend is that I am partially willing to give MS a pass and conclude perhaps it was just a bug / code defect I assume none of that shit was actually transmitted. I trust Micro$oft. I trust US spooks enough not to make Assange suffer an unfortunate accident the moment he steps foot on US soil... yet even my naÃve self is not insane enough to believe if faced with the opportunity Assange immediately upon landing in the US would not be arrested (or whatever we are calling it these days) for (insert god knows what) on sight.
From a government perspective what is there really not to like about bitcoin? Circulation is self limiting and all transactions might as well be posted on the front page of the New York times.
Indeed. The feds may be stupid, but even they can learn from experience, and most of them can read. So if this becomes a standard, they will at some time manage to understand the concept (possibly with outside help) and implement countermeasures. Look at Lavabit: The owner decided to use his whole company as a canary and while it worked, he had to stand up to severe legal threats that may only fail because no respective secret law was in place. It will be by now and triggering your canary could award you life in prison.
Lavabit did no such thing. All they wanted to do was comply with a pen register order without compromising their entire system in the process. Lavabit folded after they concluded it would not be possible.
As for your life in prison comment...who knows it could be the death penalty or three generations of you and your family doing hard labor NK style. We all get to hand-wave and make all the assertions we want...fun aintit?
No, the only way to deal with a police state (and in many respects the US is now one) is to leave the country and move business to the free world.
I wish to assert my 1st amendment privilege to invoke Godwin's law. Cowardice and capitulation solves nothing.
Incidentally, this whole idea is an example of engineers trying to fix human problems with technology. That does not work. Data leakage, privacy invasion, online fraud, surveillance, etc. all cannot be fixed with technology.
Blanket philosophical statements are rarely worth the parchment they are written.
I agree to the extent not all problems are solvable or best solved with technology including warrant canary problem.
However we should not forget modern surveillance problems have arisen from availability of enabling technology. There is little reason careful use of the same technology could not be used to put the enablement genie back into its bottle.
What if Google decided to say, "fuck it", and not only publicly post when they're asked for data, but details as to which accounts, what data.... everything!
I think we have to be careful to specify the context of what we are taking about. For example I know of no credible consensus around the idea lawful government requests by an actual non-puppet court based on specific articulable facts for specific user accounts that an operator should be free and clear to tell the world who is suspected of x, y and z. I personally don't support this view. The US constitution clearly grants government right to search when evidentiary requirements are met.
However if government decides to break the law or hire an army of legal weasels to circumvent intent to "secretly" do whatever the fuck they please then by all means fuck 'em. As far as I know legal theory allowing government to ***collect*** records of all calls made within the US is still "classified".
Saying "fuck it" and daring government to pursuit legal action against you is a great albeit perilous way to gain standing to get a legal judgment against current environment of overreach both in terms of patriot acts total abuse of third party doctrine and nonsensical paranoia based garbage to restrict posting of even aggregate statistics. There are most likely safer ways to bring about the same outcomes than saying "fuck it". Ask a lawyer.
Technically I might use RFC6797 as a template except rather than specifying max-age a next-canary parameter communicates frequency at which new canaries are to be expected. next-canary = 0 is invalid and must be ignored. (Once header is sent there are no take-backs) Benefit of this approach comes from leveraging existing browser infrastructure already in place for HSTS.
While nobody can really be sure whether warrant canaries will get you into trouble or whether secret laws allow for you to be compelled to circumvent at least in the US I'm guessing interval at which they are posted and mechanics are somewhat relevant. Say in the case of a canary updated every second into an automated system sure to trigger automatic warnings to users in real-time v. annual new years blog entry post using different words each year to say "we didn't get any NSLs in the past year" whereas in a subsequent year message is subtly "We can't say whether we received any NSLs in the past year".
The larger issue is every time you try to make living with the fruits of a corrupt system (e.g. secret courts spewing secret interpretation of law) more tolerable by treating the symptoms rather than the problem you only contribute to the problem... your energy could likely be put to better use contacting your representatives or otherwise working to build public consensus against government corruption that comes with secret courts and secret interpretation of law.
There is almost no reason to write code in assembly anymore, other than "because we can", which is a fine reason for a "fun" project. However I wouldn't write assembly if I was trying to run a business. Java has the added advantage that it uses Just-In-Time compiling, so there's a lot of cases where Java, or.Net or any other language that uses an intermediate byte-code and actually outperform C.
I keep hearing the arguments but I don't see the fruits. I expect Java and.Net apps to run slow and take up irrational amounts of memory for what they do and I am rarely disappointed. I expect the handful of ASM function libraries we use to significantly outperform c code and they always do.
If these high level languages are so great where are the commensurate outcomes in real life? Where are the cutting edge Java and.Net games? Browsers? Operating systems?
In cases where the developers time is worth substantially less than outcomes where reliability and performance are required why is the market not running to high level languages if the compiler is king?
I assume that if they do care, their easiest point of attack would just be to be enormous rules-lawyering dickheads about every last detail of PCI compliance,
With regards to PCI why would these guys have to care? PCI is not law and the only teeth PCI compliance has comes in the form of merchant relationships issuers/card vendors. If your not in that path industry can make all the rules it wants and you are free to ignore them because they can't touch you.
The switch ought to be tested periodically to make sure it is in full working order modeled after monthly testing of the emergency broadcast system here in the states.
Given cataclysmic apocalypse sure to ensue if kill switch were needed then failed to work properly we should demand it be well tested.
Ask the people who lost tens to hundreds of millions out of their bank accounts when a CA in Africa had their root certificate's private key stolen and thousands of fake banking sites launched mere hours later, and started collecting their credentials and draining their accounts if they thought the security was "sufficient".
If peeps had been using TLS-SRP to login to their bank accounts this would not have been possible. Fake site would be immediately detected when TLS handshake fails with a bad MAC.
What I really want to see in HTTP/2 is closer integration of the website login process and the underlying TLS crypto.
Right now those are two completely orthogonal phases. What would be ideal is to use both the logon credentials and TLS session key to produce an authenticator that is known only by those who know the password.
As it stands you can use TLS-SRP to mutually authenticate passwords in a way that does not expose password to offline attack and which produces keying material to secure the session.
There have been patches sitting in chrome and firefox ticketing systems for years to enable this. On the HTTP side you set TLS identity in an environment variable.
Why it has not been pushed out seems to be lack of interest or chicken/egg problem although Apache, curl and all the major SSL toolkits support it.
I respectfully disagree: it is not a layering violation, but in fact is entirely and explicitly within the scope of HTTPbis to specify that HTTP/2.0 is negotiated over TLS, just as it is entirely within the scope of the TLS WG to specify that TLS happens over TCP (and DTLS over UDP).
You are making a process argument about a standards organization. I am talking about what architecturally makes the most sense going forward. I am not concerned with process.
Going forward, after IETF 88, protocols (including HTTP/2.0) will very likely not be approved if they do not at least try to address this attack if it is possible to do so. Allowing the use of a protocol without a secure transport of some form is no longer tenable.
It is enough to say the protocol 'SHOULD' be used over a secure channel. We don't have the right to mandate what we think ought to be a minimum level of security to users. Not everyone is facing the same challenges or is operating in the same legal regime.
You and I may not like it reality is in the real world there are instances where all security is dropped at the perimeter or where end to end use of cryptography is otherwise restricted.
... And nothing. If you do not exchange keys over a secure medium, then it's exploitable. You don't need fancy protocol exploits... you just need to sit between two people and pretend you're the other guy to each.
Your solution was for everyone to exchange keys offline which is impractical.
If you want to believe DANE is not secure channel for establishing trust that is your choice. However unless you are willing to suggest something better that can actually be deployed at scale abstract talk and wishful thinking by itself is not helpful to anyone.
My suggestion is nothing more than a hedge against future compromise of the system. With my scheme if it is known DNSSEC is compromised at some point in the future it would have no effect on those who have already established a trust relationship which at any given time would be the majority of network users. It would at least mitigate damage and buy time to get the problem fixed. Better than nothing, better than wishful thinking.
That is precisely the attitude that made IPSEC a bloated pig that's almost impossible for mortal man to configure: 'Who is to say there is no value in an IPSEC connection with no encryption?'
I think HTTP/2 should resist the temptation to concern itself with security, concentrate on efficiently spewing hypertext and address security abstractly and cleanly at a separate layer from HTTP/2. Obviously as with HTTP/1 there are some layer dependencies but that is no excuse for even having a conversation about http vs https or opportunistic encryption. It is the wrong place.
Things change who knows some day someone may want to use something other than TLS with HTTP/2. They should be able to do so without having to suffer. Not respecting layers is how you end up with unnecessarily complex and ridged garbage.
For example who is to say there is no value in HTTP/2 over an IPsec protected link without TLS?
I think that it's already been proving that centralizing anything leads to corruption and manipulation. Whether you put it in DNS, or put it in a CA, the result is the same: Centralized control under the auspices of a third party. Any solution that doesn't allow all the power to stay in the hands of the server operator, must be rejected.
Except at the end of the day you have to trust *something* and DANE is a heck of a lot better than CAs. Technical information and signing ceremony protocol intended to build trust is open and transparent. http://www.root-dnssec.org/
As a practical matter you could use DANE simply as a more secure initial "leap of faith" and immediately work to establish a more personal trust relationship by some other means (Working zero knowledge proof for credential possession to secure your network session)
If everyone adopted this approach it would tend to limit pressure to undermine global trust anchors, limit damage due to any compromise and severely upset phishing and CA communities.
I do not fully trust the author because as far as I understand the baseband processor is supposed to control only the radio and nothing else. That means wifi, gsm and bluetooth. I don't understand why the baseband would have to deal with anything else, and why it would be the master processor and not just a blackbox "device" that the main OS sees and communicates with, in a properly isolated fashion. But then again I'm not knowledgeable enough to be certain about any of this.
In some smartphones RAM is shared between baseband and application processors presumably to reduce the BOM/cost.
In this case baseband effectively has root access it can read and write to anything it wants.
Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry.
Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good. Sure all of those things help *ALOT* except still not good enough I still wouldn't trust it to protect my user database. Operating under a secure syskey mode is prudent.
MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.
Still waiting for WP8 wireless to even warn the user before completely failing to validate TLS certificates. Bad enough when a vendor makes a mistake when designing a protocol... When implementing something they KNOW to be totally insecure by *design*.. now that represents a whole new realm of incompetence.
It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.
This is only because it is in Microsoft's best interests their signatures not be hacked as it would among other things doom the trusted platform. They don't seem to have the same level of concern about our passwords being compromised.
Worth noting even with known attacks SHA-1 is still plenty secure for signatures... For all we know SHA-1 may never see a serious exploit but SHA-2 could be broken tomorrow. (Devil you know vs the one you don't) SHA-1 at least has had some exposure to the real world for a number of years.. SHA-2 currently very little.
I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed. Virtually impossible to quickly resign global trust hierarchy even less feasible to resign code to react to a serious breach.
All of the drives we buy today are advertised at 1-1.4 million MTBF and cheap as hell nothing special about them. Obviously I have no idea what manufacturer rated MTBF of the disks they purchased were however I find it hard to believe it would be significantly lower.
At 1m MTBF after 4 years the failure rate should be closer to 2% than 20%.
Thinking back to previous insane reports from Google and bit errors in RAM it is very hard for me to trust any of these "studies".
For all I know something is screwed up in their environment.. vibration, temperature, supply power, power management, grounding/interference or bad batch biasing outcomes.
Neither should it be dismissed this report comes from an online backup company where there is a fairly direct and obvious conflict of interest.
Could be that most download hoarders are finally coming to their senses that out of the 250gigs of MP3s they've downloaded they're really only listening to about 2gigs worth? That's my guess
Your a fool if you only listen to 2gigs worth of MP3's you'll end up hating all of your favorite songs before the year is out.
The Russian said this example shows that not being connected to the internet does not prevent you from being infected.
As any G20 attendees receiving a malware infested Russian USB stick would attest.
For those of us alive before most had even heard of "Internet" viruses then had no problem running rampant thought the world often by sneaker net, BBS or by private networks with no outside connectivity.
What is strange to me everything is so scripted astronauts often end up being more or less robots executing procedures from manuals or commanded to do so from ground.
The second part of the puzzle you would think everything going up is tested and signed off on by at least someone?? Do people these days just scrounge up USB sticks they had laying around the office before heading off to the ISS?
I don't understand the amateur hour permissive environment enabling this to occur.
b) add some proper authentication and encryption in HTTP2.0 instead of bitching that it's the wrong layer. it's clear no-one is going to adopt HTTPS
widely anytime soon; most websites require you to login, meaning you can perform encrypted key exchange (EKE) with them, which allows for two-way authentication, plus encryption optionally;
Lets not even think about it. Not only is it the wrong layer inventing new protocols that don't even exist yet thinking they will be adopted any sooner than throwing the switch on SSL on existing systems is about as silly as not caring about it being the WRONG LAYER.
A solution is mostly implemented in the form of TLS-SRP. RFCs already written, SSL toolkits already support it, patches exist for major browsers and web severs such as Apache already support it.
Using a TLS-SRP patched browser you enter your login credentials for Slashdot into a browser login field - it then goes out and establishes a secure connection to Slashdot based not on certificates / CA shenanigans but upon mutual knowledge of a common password.
Slashdot Mirror
Federal officials have anonymously granted immunity to all who confess here (No Anonymous Cowards!) to drunken driving, porn viewing, shoplifting, debauchery, and hacking.
Speaking of hacking... have you ever heard the disks rumbling on your workstation and wonder to yourself WTF was THAT all about? It can be especially unsettling when all disk activity stops the instant you move your mouse to look into what all was going on.
Afraid of having been hax0rd looked into it using standard sysinternals goodness and cought Microsofts CEIP red-handed systematically alphabetically scanning thru folders and files on my computer on a separate data volume from the OS even while CEIP had been completely disabled in action center from day one. The task history clearly shows minutes of runtime activity (Why would it ever need to do anything if it were disabled?) it even logged suspension of itself in reaction to my mouse movements to wake from idle. To confirm and gather data I waited for the 10 minute idle period to record system calls made while it resumed scanning the volume to completion right from where it left off twice previously.
All CEIP tasks have been subsequently disabled from task scheduler.
What I find impossible to comprehend is that I am partially willing to give MS a pass and conclude perhaps it was just a bug / code defect I assume none of that shit was actually transmitted. I trust Micro$oft. I trust US spooks enough not to make Assange suffer an unfortunate accident the moment he steps foot on US soil... yet even my naÃve self is not insane enough to believe if faced with the opportunity Assange immediately upon landing in the US would not be arrested (or whatever we are calling it these days) for (insert god knows what) on sight.
From a government perspective what is there really not to like about bitcoin? Circulation is self limiting and all transactions might as well be posted on the front page of the New York times.
Indeed. The feds may be stupid, but even they can learn from experience, and most of them can read. So if this becomes a standard, they will at some time manage to understand the concept (possibly with outside help) and implement countermeasures. Look at Lavabit: The owner decided to use his whole company as a canary and while it worked, he had to stand up to severe legal threats that may only fail because no respective secret law was in place. It will be by now and triggering your canary could award you life in prison.
Lavabit did no such thing. All they wanted to do was comply with a pen register order without compromising their entire system in the process. Lavabit folded after they concluded it would not be possible.
As for your life in prison comment...who knows it could be the death penalty or three generations of you and your family doing hard labor NK style. We all get to hand-wave and make all the assertions we want...fun aintit?
No, the only way to deal with a police state (and in many respects the US is now one) is to leave the country and move business to the free world.
I wish to assert my 1st amendment privilege to invoke Godwin's law. Cowardice and capitulation solves nothing.
Incidentally, this whole idea is an example of engineers trying to fix human problems with technology. That does not work. Data leakage, privacy invasion, online fraud, surveillance, etc. all cannot be fixed with technology.
Blanket philosophical statements are rarely worth the parchment they are written.
I agree to the extent not all problems are solvable or best solved with technology including warrant canary problem.
However we should not forget modern surveillance problems have arisen from availability of enabling technology. There is little reason careful use of the same technology could not be used to put the enablement genie back into its bottle.
What if Google decided to say, "fuck it", and not only publicly post when they're asked for data, but details as to which accounts, what data.... everything!
I think we have to be careful to specify the context of what we are taking about. For example I know of no credible consensus around the idea lawful government requests by an actual non-puppet court based on specific articulable facts for specific user accounts that an operator should be free and clear to tell the world who is suspected of x, y and z. I personally don't support this view. The US constitution clearly grants government right to search when evidentiary requirements are met.
However if government decides to break the law or hire an army of legal weasels to circumvent intent to "secretly" do whatever the fuck they please then by all means fuck 'em. As far as I know legal theory allowing government to ***collect*** records of all calls made within the US is still "classified".
Saying "fuck it" and daring government to pursuit legal action against you is a great albeit perilous way to gain standing to get a legal judgment against current environment of overreach both in terms of patriot acts total abuse of third party doctrine and nonsensical paranoia based garbage to restrict posting of even aggregate statistics. There are most likely safer ways to bring about the same outcomes than saying "fuck it". Ask a lawyer.
Technically I might use RFC6797 as a template except rather than specifying max-age a next-canary parameter communicates frequency at which new canaries are to be expected. next-canary = 0 is invalid and must be ignored. (Once header is sent there are no take-backs) Benefit of this approach comes from leveraging existing browser infrastructure already in place for HSTS.
While nobody can really be sure whether warrant canaries will get you into trouble or whether secret laws allow for you to be compelled to circumvent at least in the US I'm guessing interval at which they are posted and mechanics are somewhat relevant. Say in the case of a canary updated every second into an automated system sure to trigger automatic warnings to users in real-time v. annual new years blog entry post using different words each year to say "we didn't get any NSLs in the past year" whereas in a subsequent year message is subtly "We can't say whether we received any NSLs in the past year".
The larger issue is every time you try to make living with the fruits of a corrupt system (e.g. secret courts spewing secret interpretation of law) more tolerable by treating the symptoms rather than the problem you only contribute to the problem... your energy could likely be put to better use contacting your representatives or otherwise working to build public consensus against government corruption that comes with secret courts and secret interpretation of law.
I've never heard of anyone having any security issues with Foxit.
http://www.foxitsoftware.com/Secure_PDF_Reader/security_bulletins.php
There is almost no reason to write code in assembly anymore, other than "because we can", which is a fine reason for a "fun" project. However I wouldn't write assembly if I was trying to run a business. Java has the added advantage that it uses Just-In-Time compiling, so there's a lot of cases where Java, or .Net or any other language that uses an intermediate byte-code and actually outperform C.
I keep hearing the arguments but I don't see the fruits. I expect Java and .Net apps to run slow and take up irrational amounts of memory for what they do and I am rarely disappointed. I expect the handful of ASM function libraries we use to significantly outperform c code and they always do.
If these high level languages are so great where are the commensurate outcomes in real life? Where are the cutting edge Java and .Net games? Browsers? Operating systems?
In cases where the developers time is worth substantially less than outcomes where reliability and performance are required why is the market not running to high level languages if the compiler is king?
I assume that if they do care, their easiest point of attack would just be to be enormous rules-lawyering dickheads about every last detail of PCI compliance,
With regards to PCI why would these guys have to care? PCI is not law and the only teeth PCI compliance has comes in the form of merchant relationships issuers/card vendors. If your not in that path industry can make all the rules it wants and you are free to ignore them because they can't touch you.
The switch ought to be tested periodically to make sure it is in full working order modeled after monthly testing of the emergency broadcast system here in the states.
Given cataclysmic apocalypse sure to ensue if kill switch were needed then failed to work properly we should demand it be well tested.
Ask the people who lost tens to hundreds of millions out of their bank accounts when a CA in Africa had their root certificate's private key stolen and thousands of fake banking sites launched mere hours later, and started collecting their credentials and draining their accounts if they thought the security was "sufficient".
If peeps had been using TLS-SRP to login to their bank accounts this would not have been possible. Fake site would be immediately detected when TLS handshake fails with a bad MAC.
What I really want to see in HTTP/2 is closer integration of the website login process and the underlying TLS crypto.
Right now those are two completely orthogonal phases. What would be ideal is to use both the logon credentials and TLS session key to produce an authenticator that is known only by those who know the password.
As it stands you can use TLS-SRP to mutually authenticate passwords in a way that does not expose password to offline attack and which produces keying material to secure the session.
There have been patches sitting in chrome and firefox ticketing systems for years to enable this. On the HTTP side you set TLS identity in an environment variable.
Why it has not been pushed out seems to be lack of interest or chicken/egg problem although Apache, curl and all the major SSL toolkits support it.
I respectfully disagree: it is not a layering violation, but in fact is entirely and explicitly within the scope of HTTPbis to specify that HTTP/2.0 is negotiated over TLS, just as it is entirely within the scope of the TLS WG to specify that TLS happens over TCP (and DTLS over UDP).
You are making a process argument about a standards organization. I am talking about what architecturally makes the most sense going forward. I am not concerned with process.
Going forward, after IETF 88, protocols (including HTTP/2.0) will very likely not be approved if they do not at least try to address this attack if it is possible to do so. Allowing the use of a protocol without a secure transport of some form is no longer tenable.
It is enough to say the protocol 'SHOULD' be used over a secure channel. We don't have the right to mandate what we think ought to be a minimum level of security to users. Not everyone is facing the same challenges or is operating in the same legal regime.
You and I may not like it reality is in the real world there are instances where all security is dropped at the perimeter or where end to end use of cryptography is otherwise restricted.
... And nothing. If you do not exchange keys over a secure medium, then it's exploitable. You don't need fancy protocol exploits... you just need to sit between two people and pretend you're the other guy to each.
Your solution was for everyone to exchange keys offline which is impractical.
If you want to believe DANE is not secure channel for establishing trust that is your choice. However unless you are willing to suggest something better that can actually be deployed at scale abstract talk and wishful thinking by itself is not helpful to anyone.
My suggestion is nothing more than a hedge against future compromise of the system. With my scheme if it is known DNSSEC is compromised at some point in the future it would have no effect on those who have already established a trust relationship which at any given time would be the majority of network users. It would at least mitigate damage and buy time to get the problem fixed. Better than nothing, better than wishful thinking.
That is precisely the attitude that made IPSEC a bloated pig that's almost impossible for mortal man to configure: 'Who is to say there is no value in an IPSEC connection with no encryption?'
I'll see your IPSEC and raise you an H323.
I think HTTP/2 should resist the temptation to concern itself with security, concentrate on efficiently spewing hypertext and address security abstractly and cleanly at a separate layer from HTTP/2. Obviously as with HTTP/1 there are some layer dependencies but that is no excuse for even having a conversation about http vs https or opportunistic encryption. It is the wrong place.
Things change who knows some day someone may want to use something other than TLS with HTTP/2. They should be able to do so without having to suffer. Not respecting layers is how you end up with unnecessarily complex and ridged garbage.
For example who is to say there is no value in HTTP/2 over an IPsec protected link without TLS?
I think that it's already been proving that centralizing anything leads to corruption and manipulation. Whether you put it in DNS, or put it in a CA, the result is the same: Centralized control under the auspices of a third party. Any solution that doesn't allow all the power to stay in the hands of the server operator, must be rejected.
Except at the end of the day you have to trust *something* and DANE is a heck of a lot better than CAs. Technical information and signing ceremony protocol intended to build trust is open and transparent.
http://www.root-dnssec.org/
As a practical matter you could use DANE simply as a more secure initial "leap of faith" and immediately work to establish a more personal trust relationship by some other means (Working zero knowledge proof for credential possession to secure your network session)
If everyone adopted this approach it would tend to limit pressure to undermine global trust anchors, limit damage due to any compromise and severely upset phishing and CA communities.
I do not fully trust the author because as far as I understand the baseband processor is supposed to control only the radio and nothing else. That means wifi, gsm and bluetooth. I don't understand why the baseband would have to deal with anything else, and why it would be the master processor and not just a blackbox "device" that the main OS sees and communicates with, in a properly isolated fashion. But then again I'm not knowledgeable enough to be certain about any of this.
In some smartphones RAM is shared between baseband and application processors presumably to reduce the BOM/cost.
In this case baseband effectively has root access it can read and write to anything it wants.
Please come back my crappy antenna needs all the help it can get.
MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.
Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.
Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry.
Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good. Sure all of those things help *ALOT* except still not good enough I still wouldn't trust it to protect my user database. Operating under a secure syskey mode is prudent.
MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.
Still waiting for WP8 wireless to even warn the user before completely failing to validate TLS certificates. Bad enough when a vendor makes a mistake when designing a protocol... When implementing something they KNOW to be totally insecure by *design* .. now that represents a whole new realm of incompetence.
It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.
This is only because it is in Microsoft's best interests their signatures not be hacked as it would among other things doom the trusted platform. They don't seem to have the same level of concern about our passwords being compromised.
Worth noting even with known attacks SHA-1 is still plenty secure for signatures... For all we know SHA-1 may never see a serious exploit but SHA-2 could be broken tomorrow. (Devil you know vs the one you don't) SHA-1 at least has had some exposure to the real world for a number of years.. SHA-2 currently very little.
I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed. Virtually impossible to quickly resign global trust hierarchy even less feasible to resign code to react to a serious breach.
As drives get larger (4TB is now readily available) they are not getting any faster.
Sequential I/O increases with bit/area density although perhaps not at the same rate.
All of the drives we buy today are advertised at 1-1.4 million MTBF and cheap as hell nothing special about them. Obviously I have no idea what manufacturer rated MTBF of the disks they purchased were however I find it hard to believe it would be significantly lower.
At 1m MTBF after 4 years the failure rate should be closer to 2% than 20%.
Thinking back to previous insane reports from Google and bit errors in RAM it is very hard for me to trust any of these "studies".
For all I know something is screwed up in their environment.. vibration, temperature, supply power, power management, grounding/interference or bad batch biasing outcomes.
Neither should it be dismissed this report comes from an online backup company where there is a fairly direct and obvious conflict of interest.
Could be that most download hoarders are finally coming to their senses that out of the 250gigs of MP3s they've downloaded they're really only listening to about 2gigs worth? That's my guess
Your a fool if you only listen to 2gigs worth of MP3's you'll end up hating all of your favorite songs before the year is out.
The Russian said this example shows that not being connected to the internet does not prevent you from being infected.
As any G20 attendees receiving a malware infested Russian USB stick would attest.
For those of us alive before most had even heard of "Internet" viruses then had no problem running rampant thought the world often by sneaker net, BBS or by private networks with no outside connectivity.
What is strange to me everything is so scripted astronauts often end up being more or less robots executing procedures from manuals or commanded to do so from ground.
The second part of the puzzle you would think everything going up is tested and signed off on by at least someone?? Do people these days just scrounge up USB sticks they had laying around the office before heading off to the ISS?
I don't understand the amateur hour permissive environment enabling this to occur.
b) add some proper authentication and encryption in HTTP2.0 instead of bitching that it's the wrong layer. it's clear no-one is going to adopt HTTPS
widely anytime soon; most websites require you to login, meaning you can perform encrypted key exchange (EKE) with them, which allows for two-way authentication, plus encryption optionally;
Lets not even think about it. Not only is it the wrong layer inventing new protocols that don't even exist yet thinking they will be adopted any sooner than throwing the switch on SSL on existing systems is about as silly as not caring about it being the WRONG LAYER.
A solution is mostly implemented in the form of TLS-SRP. RFCs already written, SSL toolkits already support it, patches exist for major browsers and web severs such as Apache already support it.
Using a TLS-SRP patched browser you enter your login credentials for Slashdot into a browser login field - it then goes out and establishes a secure connection to Slashdot based not on certificates / CA shenanigans but upon mutual knowledge of a common password.