Fast track to offense
And just like that, the flag which has been around for over a century has suddenly become "offensive imagery" overnight and requires immediate eradication. This is the state our world now lives in.
87 posts • joined 13 Aug 2008
And just like that, the flag which has been around for over a century has suddenly become "offensive imagery" overnight and requires immediate eradication. This is the state our world now lives in.
Why mess with Ghost when CloneZilla does it for free (and with a Live CD/USB)?
"In particular, Verizon said that while it can lay fiber under the streets, actually getting it into buildings is another matter."
Hmmm... Maybe they shouldn't have come up with that agreement if it's something they couldn't do, eh? The article doesn't make it clear if this was some sort of signed contract or just mutual agreement.
Backblaze also created a home grown solution to large quantities of data storage, also using Reed-Solomon versus traditional hardware RAID. It has some pretty impressive scalability (in theory). Some of the concepts seem similar to Facebook's solution, although they didn't put much focus on reducing power consumption and the like.
It's a very interesting read
The situation we are in now is a little like trying to put the toothpaste back in the tube.
You can run an implicit SSL SMTP server on port 465 (port 993 is IMAPS, btw) and other could connect, but a much larger percentage of the SMTP servers out there don't do this versus those that do. The only way you would know is if you attempt a connection first (which will most likely fail), and then you have to fall back to regular port 25 anyway, thus increasing the overhead for sending emails.
Fundamentally, an implicit SSL connection and a clear text connection where you issue STARTTLS are the same, but the advantage of STARTTLS is that you only have to connect to one port (which should always be open for any public SMTP server), and you can then secure up the session. Granted, you might have the fallback to an unecrypted session depending on the client/server config. It is possible to set up some SMTPd servers to require TLS when connecting to remote servers, even by using STARTTLS, but you still end up in the same situation (many servers do not support it).
Now, if the government enable STARTTLS functionality for inbound and outbound, it still relies on the other client and server to support it. They can't force that to be the case, and if it's not supported on the other end, it defeats the implementation anyway. Thus, implementing the change might give some a false sense of security just to tick another box on the security checklist. I'm not saying they shouldn't implement this at all, however.
"There was a concern that the appeals court's judgment could set a precedent, encouraging organizations or anyone with a chip on their shoulder to trample on free speech by demanding the identities of anonymous reviewers posting online. The threat of legal action against those who write negative reviews will have a chilling effect on free expression."
The flip side is also true. Let's assume for the moment that the anonymous person posting the review WAS fake or not a customer. Depending on what they said, it could be considered libel, which has legal recourse. Should a person be protected under "free speech" for libel just because they made themselves anonymous? Think about how fast false information can travel these days. It used to be much harder back in the days before widespread internet to anonymously spread misinformation. Nowadays, it's incredibly easy.
As far as the solution (at least in this case)? Maybe set up some third party to authenticate whether the person was actually a client without the carpet company being told who it is. That might be hard to do while maintaining privacy for the actual customer list.
"These would be kids who are too young to enter into a legal contract. Sorry, the responsibility for the laptops remains with the last legally responsible entity who had them"
So given that rationale and returning to my previous scenario of a neighbor borrowing something, you'd be perfectly content if the neighbor never returned said item or conveniently lost it since you never had a legal contract between the two of you explaining the terms of the loan?
I'm not arguing from a LEGAL standpoint. I'm arguing from a responsibility stand point. There are plenty of situations where someone cannot be LEGALLY held responsible for something, but that doesn't make it right or something that should be swept under the rug.
"But how would you feel if your boss made you take home an expensive piece of equipment everyday and told you that you were responsible for any loss or damage - you would tell him to stick it."
It's called being responsible. If you have the attitude of "I'm not going to take care of something because it doesn't actually belong to me", then maybe people should stop giving you stuff on their dime. Would you rather the boss say "Go buy your own laptop so you are solely responsible for it"? What if you loaned something to a neighbor, and it was lost or stolen. Would you not think the neighbor is accountable for it?
And in this case, according to the article, the kids were not forced to take them home, they were ALLOWED to take them home (at least until they were "hacked").
By disabling SSLv3, you really don't cut off that many people (communication via older scripts could be a different story). PFS is recommended, but that's not what this is talking about.
Android 2.3.7 - Uses TLS 1.0
IE7 on Vista - Uses TLS 1.0
IE8 on WinXP - Uses TLS 1.0
Safari 5 on OS X 10.6.8 0 - Uses TLS 1.0
Safari 6 on iOS 6 - Uses TLS 1.2
Does not work:
IE6 on WinXP - Uses SSLv3
I'm sorry, but if you are really that concerned about cutting off IE6 users on Windows XP, then you need to contact those people and tell them to get their act together. Either upgrade off an unsupported OS or switch to an alternate browser that was written in the past decade.
(note: I don't use Comcast, so I don't know their physical infrastructure)
Why the bump to 2Gbps, aside from a one-upsmanship towards Google? To fully benefit, I assume this means you'll have to use the ISP supplied router, since running such a device in bridge mode will basically lock you down to 1Gbps (how many people have 10Gbps interfaces at home?). Additionally, so many people do things over wireless nowadays (laptops, cell phones, tablets), you'll still have a bigger bottleneck there.
Do they just want to say "Hey, our number is twice as big, so we are twice as fast!" (although past comments from Comcast users seem to indicate the ISP throttling will bring it down much lower)?
The big question that I still have that I haven't really seen answered anywhere (primarily since the rules just came out) is whether this affects QoS-type transmissions.
The biggest thing I see toted is "you can't sell 'fast lanes' to a company to give their traffic higher priority" (which seems good on the surface), but I've also seen people say "you can't discriminate traffic". For services that require low latency (say VoIP or anything real-time between two or more people), how do the new rules apply? You could easily say that giving VoIP traffic a higher priority is discriminating against Joe Schmoe's torrent download, but if everything is a free-for-all FIFO/round robin approach, things will collapse.
I obviously haven't read through it (that's a long set of rules), but I'm hoping someone as a take on this based upon the new rules.
"I'm curious, what do people need SD cards for?"
Personally, I don't use it for the extra capacity that much. I use it because it is REMOVABLE storage. It's an easy way to get large amounts of data on or off the phone. I can also perform periodic backups with Titanium Backup, which means if the phone conks out, I can still have a copy of my data that doesn't require some on-line cloud-esque sync solution. Granted, ad SD card can die too, but a phone dying takes a lot more down with it.
"There's nothing "only" about a flaw that exposes usernames and password in plaintext."
Although the POTENTIAL was there to expose usernames and passwords, it was still wildly a crap shoot as to what information you could actually obtain from the random memory locations. The fact that you couldn't easily detect an attack is what made it so hard to accurately determine the level of the data leak.
So what's to stopping them from just using the "high speed internet access" instead? Unless that term is explicitly defined somewhere, I don't see it having the effect that they hope it will have.
RUD - Rapid Unscheduled Disassembly
I love it! I'm going to start using that instead of things "break", "crash", or "destroy"
There are a surprising number of "odd" characters that are considered valid in an email address per RFC specs (the plus sign being a definitive yes).
And RFC 821 has been obsoleted by RFC 2821, which has been obsoleted by RFC 5321.
Exactly. The math is off somewhere (or the description of the numbers)
4,000 CPUs each doing 6 billions hands a second = 24,000 billion hands a second
They say more a billion billion hands (1,000,000,000 billion)
1,000,000,000 / 24,000 = 41,666 seconds (less than half a day)
They ran the simulation for 2 months = about 5,184,000 seconds
At that rate, it would calculate about 124 billion billion hands.
As suggested, clock cycles makes much more sense.
"The standard itself was developed at record speed as cable companies started to worry about the arrival of competitors, such as Google Fiber."
And this is exactly why competition in the technology space is so important. If this wasn't there, how long do you think it would be before they decided to even look into this kind of upgrade?
"If they are trying to figure out how to get astronauts through the VARB then it is because they have never done it before."
And I guess you're also one of the people that complains about the lack of stars in the pictures? And the "inconsistent" shadows? And the "too perfectly framed" pictures on the moon? And the "too perfect video" of Apollo 17's lunar lift off? And the "earth transparency overlays" used in the video shot through the Apollo 11 window?
A little research goes a long way. Much more so than the trite theories being recycled.
In additional to the "convenient" dynamic DNS supported by Foscam devices, some devices will attempt to use UPnP to dynamically forward ports to the camera/NVR device. If your router supports this by default (for example, the ActionTec provided for Verizon FiOS), the device can (unbeknownst to the end user) make itself accessible to the outside world.
I've had this experience with a Q-SEE NVR (although I had read the included "quick setup" guide that mentioned how to access it remotely, so I knew it was doing that). Although changing the default password will "lock it down", it is still a bad idea for the default setting to be "punch holes in my firewall". Come to think of it, I don't even know if the NVR HAD the ability to disable UPnP
That's not how a typical SSL MITM attack works.
Normally, a nefarious system will try to intercept the end user's traffic secretly. It would do this by jumping in between the two end points of the connection. To make it seamless, the bad guy would need to decrypt an already encrypted session, which is theoretically difficult (although the practicality of it changes over time). If the bad guy doesn't have the server's private key, it has to rely on exploits or weaknesses in the encryption.
Now pretend the private keys of the CA were compromised. This allows someone to sign their own certificates that browsers will automatically trust. It doesn't involve breaking or compromising the encryption of the two end points. In essence, the MITM attack becomes more of a reverse proxy.
Ultimately, that's no different than any other CA getting their private keys compromised. It still has nothing to do with the private keys of the original server providing the SSL connection.
What does this have to do with keys? They wouldn't have the private keys to decrypt the data. Only you would have those (installed on the server). All they are doing is signing a certificate to let others know it can be trusted (assuming the CA is included in the browser). They only get a CSR signed by your private key, not your actual private key. It's the whole point of asymmetrical encryption (e.g. public-key cryptography).
FYI, for those that are familiar with MAME, you can configure controls the same way.
Press 'P' to pause the emulation, then press the Tab key to bring up the config menu.
"We really should see somehow where the huge profits generated online go, and whether there is a way to keep some of it in Hungary"
How would putting a tax on data usage "keep it in Hungary"? That would imply that the tax money the people are forced to pay would normally be going to pay for something elsewhere. It's not a sudden shift in the money's destination. If anything, you take money away from what a person can spend on other things, which a majority of the time is already spent in the country (rent, utilities, gas, car payments, insurance, etc).
"Justice Department officials are 'reluctant to bring criminal charges involving unauthorized disclosures to the news media' – because of criticisms of the tactics used in recent leak investigations"
We don't like it when the media hears about the bad things that we do and then say we are doing bad things and make us look bad.
"It's feared the web toll will be passed onto subscribers by the ISPs"
"... won't cough admin privileges to the hacker – at least not by itself. Attacks are likely to generate pop-up warnings and under default settings a User Access Control popup would get displayed."
Ohhh, you mean that "this program is requesting admin rights" pop up where everyone just clicks Yes when they see it?
"The point is ... no one from apple cares. They keep being silent. They used to care about their customers but now..."
How long have you known Apple? Sounds about par for the course... Everyone knows that there are never any problems with their hardware, only the end user.
Netflix complains that the speed issues are due to the end user's ISP. The ISP says it's because Netflix is sending traffic over other upstream providers that don't have the capacity to carry the traffic. Yet now, Netflix creates another peering agreement with another ISP. They even have a peering agreement arranged (but maybe not implemented) with Verizon, but they had their recent spat over who's at fault for the slow down.
What in the world am I missing? Netflix complains that the problem is with someone else, then they establish peering agreements with those parties. Are they just trying to make the ISP look like the bad guy? Is Netflix just bi-polar?
Hmmm... Methinks this would be a good way to suck up more IPv4 addresses and push more toward IPv6 (not really, but hey, it's Google). It's too bad we can't just all assume that SNI will work everywhere, although with the "death" of Windows XP, there should be less resistance, in theory.
Irony alert: When the Heartbleed bug was discovered, you would have actually been a little safer to NOT be using SSL, as you wouldn't have had the potential for private keys to be stolen and allowed a third party to impersonate your site over a secure connection (although nowadays, I'm sure a large percentage of netizens don't pay as much attention as they should to whether a connection is secure or not).
Just like people call because McDonald's gets their order wrong or they are out of a particular food item.
This is the unfortunate world we now live in...
There are a lot more than just 13 root name servers
"Yes, he loves them so much that he's actually only 21st out of 44 for number of executive orders issued (182 as of June 20.) See also: http://www.presidency.ucsb.edu/data/orders.php"
Uggh... This argument again? The NUMBER of executive orders DOES NOT MATTER. It's the CONTENT of those executive orders that matters. If one president issued 500 executive orders that did small, non-law creating things, that would be so much better than a president that issued just one executive order that established a new law that made everyone take 15 minutes our of every day to personally bow down to him or risk imprisonment. He's already riding the line when it comes to what power he is actually granted by the constitution.
Now, back on topic...
"Aereo even found three Supreme Court Justices who agreed with it. Six Justices, however, didn't, sticking broadly to the common sense and widely accepted principles of property and compensation."
Putting the "spirit of the law" aside for a moment, let's look at this scenario.
(I am assuming the one-to-one antennae aspect of Aereo is true, as they say)
An end user goes out and buys an antennae to receive over the air broadcasts. He hooks up said antennae to a capture card on the computer and uses some form of PVR software. The net result? The end user is getting the same content as the Aereo service (at least at the location of antennae installation) for a one time hardware payment. No money has gone to the broadcasters, following the "common sense and widely accepted principles of property and compensation". Yet this scenario is perfectly legal.
Let's take the DVR aspect out of it for the Aereo service. Now, a user only has access to a live stream of whatever is being broadcast at the time. Take that technology and put it in a USB dongle, and now it's portable. Assuming the verdict would be the same if Aereo did not provide DVR service (I wonder if it would have been), the former method is illegal but the latter is legal.
Since (I assume) the Aereo service could be accessed from any Internet just by logging in to a user's account, it's not quite as straight forward, but the principle is still relevant.
"... new legislation that limits firms’ ability to control prices could also cause foreign suppliers to abandon or decide not to enter the Australian market, resulting in less competition and less choice for consumers in Australia."
Assuming that the final prices being charged are stilling providing a profit, I'm pretty sure if a company is given the choice of "no profit" (exit the market) versus "some profit" (stay in at a lower margin), they would choose the latter.
If ARIN actually wanted to help with the adoption of IPv6, they would make it more cost effective (i.e. free) to at least get your feet wet with it. As far as I know, there's no way to get a free "test" block of IPv6 addresses from ARIN for experimenting with a publicly accessible IPv6 setup. At the very least, they should have made IPv6 addresses available for people with existing direct IPv4 allocations. If I had access to an IPv6 block and I didn't have to try to justify an associated cost with management for something that is just being tested, I'd definitely show more interest in playing around with it.
Think about it. A large portion of the "value" associated with an IPv4 address is because of supply and demand. For IPv6, the "demand" is essentially not there, not because so few people are deploying it, but because there are so many addresses available that every micro-organism could be assigned one and we'd still have plenty to spare. This eats into ARIN's bottom line, so they have to start out by establishing a dollar value for IPv6 that's not anywhere close to its real value (e.g. millionths of a cent per IP)
Wait... You think that the owner of a team can't be a control freak that wants to do things his way for the better of the team? Just look at how well it's work for the Dallas Cowboys.
'According to Cohen, the move is all about fairness. 'People who use more should pay more and people who use less should pay less,' he said.'
So given your example, people that use less than the 300GB get a discount right? Oh, that's right. The base price would include up to 300GB for everyone at the same price, regardless of what percentage of people are using a lot less than that. Almost sounds like a redistribution of the wealth.
Reading some of these posts, it seems there might be a lot of misinformation regarding the technical implications of Heartbleed. Without writing a huge article, here's a brief overview of critical points.
The flaw affects BOTH servers AND clients. The heartbeat command that is generated that causes the flaw is like a ping. The server can "ping" the client and the client can "ping" the server. Granted, a server would have to be specifically set up to send malicious heartbeat packets sniffing for data, although it's still possible. Embedded devices, like routers, WiFi access points, etc. are potentially affected because they can be running a "server" too (although this should make people take a good look as to whether you really need that WiFi access point interface to be accessible to the whole internet over port 443).
A MITM attack is NOT needed for a random third party to (potentially) obtain username/passwords that are sitting around in memory on a server. All that has to be done is for someone to attack a vulnerable server with forged heartbeat packets, then sift through the returned data. Would it be difficult to find usernames and passwords? Potentially, as the leaked data is whatever random data was stored in memory at the location that was copied. It could return useful information after only one request, or it could return useful information only after 10 millions requests. Now when it comes to sifting through that data, that's a whole other issue.
A MITM attack IS required for someone to pretend they are another site, IF they happen to get a copy of the server's private key. Because of that IF, this is why people are recommending revoking SSL certificates. Just like the usernames and passwords, they might get the private key easily, or they might have a really hard time getting it. One they get the key, they still have to get the end user to visit their site (to avoid certificate warnings, they would need something like DNS cache poisoning to redirect someone to a different IP while keeping the domain the same).
As an end user, you visit a lot more than just your "ISP's server". Any web site you visit over SSL poses a potential risk.
All in all, I still agree that the media over-sensationalized this quite a bit. Odds are most people will not be affected by it. Sure there will be some (especially considering known attacks started up shortly after the vulnerability was revealed), but most will not, simple because they first have to attack a server that vulnerable, then they have to hope the server leaks the credentials, then they have to actually be credentials for you.
Kudos to the majority of the staff out there that got things patches up quickly (I'm probably a little spoiled, as I keep the 50 or so servers I manage up-to-date on a regular basis, so a simple apt-get upgrade is easy. The SSL certificate revocations was a little bit more work).
Aren't cable provider's service areas typically regionally exclusive (i.e. "this area is serviced by Comcast while this other area is serviced by Charter")? The end user generally doesn't have a choice, except possibly across different technologies (e.g. cable, FiOS, DSL, etc). Maybe the cities they mention are different...? If not, how exactly are they planning on doing this? Selling the local infrastructure with it?
And what if the client likes Comcast more than Charter? (well, I guess the answer is "tough luck")
"If the Netcraft extension determines that a site was vulnerable before news of Heartbleed broke, it checks the date on the site's SSL certificate to make sure it has been recently replaced. If it hasn't, the extension displays an alert."
Ugh... That's all fine and dandy if every CA changed the issue date on certificate reissues. I've read from multiple sources that this is not always the case. I know that GoDaddy will update the issue date, but I think Comodo is an example of one that does not update it. Without installing the extension and knowing how the "alert" is presented to the user, they could be venturing into dangerous territory by saying a site is still affected when it's truly not.
Also considering the possibility where someone was running a non-vulnerable version (0.9.8 or 1.0.0) and they upgraded their servers to now be running 1.0.0g+. Most likely they wouldn't get their cert reissued because they were never vulnerable.
They *could* have been using GnuTLS instead, but considering the extra work involved in doing that as opposed to installing the distro packages, that would be extremely unlikely.
The state of open source SSL libraries is a pretty sad affair right now. OpenSSL is the "defacto" standard mainly because it's been around for so long, but the code is so big and cumbersome, there's not a single person that knows everything about it (or probably even a large percentage). GnuTLS isn't really much better. I've read on some sites where developers dislike the GnuTLS code just as much (if not more) than OpenSSL.
Debian uses GnuTLS for some services (OpenLDAP is the first to come to mind), but they did that because of the licensing issues with OpenSSL (GnuTLS is LGPL).
OpenSSL 0.9.8 is not "dead". Yes, it's the older branch, but it still receives major security fixes. Many systems still utilize it because it's been around for so much longer than the 1.0.x series, so it (should be) more stable.
The biggest disadvantage of the 0.9.8 branch is that is doesn't support the newer ciphers suites.
I understand that the potential risk is there (and theoretically everyone COULD have already had their information exploited) and there's know what to know for sure, but the problem is the media is essentially going straight to the "doomsday" scenario when the odds are it's not nearly that extreme. However, now that world+dog knows about the exploit, I'm sure a lot more attempts are being made to capitalize on it (as evidenced by other sites mentioned by another ElReg article).
I'm not saying it would be a bad idea to change critical passwords for the sites you access, but once the majority of the big providers have patched their servers, a lot of this will blow over and the majority of people will be unaffected, IMO.
"The flaw is potentially among the most damaging ever to surface on the web but there's been little evidence that it has been widely exploited so far - leading some security experts to say it's been overblown"
The media has severely sensationalized this. The actual compromised data can range from "move along, nothing to see here" to "hide your kids, hide your wife, hide your husband"*. For the majority of the people seeing the reports (read: non-technical people), they are receiving the message that "The world is collapsing and nothing is safe. You have been compromised, change all of your passwords, PINs, combination locks, dead bolts, alarm clocks, dog's name, etc"
Yes, the *potential* for your secure data to be compromised is there, but most likely, the majority of people are just fine. It's hard to imagine that if this particular exploit was in wide use in the "hackers" underground that it wouldn't have surfaced much sooner. Think about it: the main thing the crooks want are usernames, passwords, credit cards, etc. If they've compromised those, I think you would have noticed before now.
It doesn't mean the IT departments around the globe shouldn't have due diligence patching what they can (at a minimum the OpenSSL libraries and rekeying SSL certificates where feasible), but it's not exactly "the sky is falling" scenario that is being presented.
"This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content"
This is a little misleading. There's no GUARANTEE that private keys were compromised, although it's possible (and should be assumed as a precaution). It just all depends on what happened to be in the memory location that was leaked. However, statistically the number of instances where this is true is going to be much smaller than the ones where it is not.
"Every single email message you send or receive ... is encrypted while moving internally"
Yup. Gotta be clear about that little point. INTERNALLY. Once it leaves their server, all bets are off.