I don't think banks will be using MD5 at this point in time.
That is not important. CAs that use MD5 for their cert signing are already in the browsers list of trusted CAs. It is not important what CA the banks use for their own certs for this attack to work.
I was talking about finding a new cert where the signature matches any arbitrary web site cert. That is, you can't take Citibank's cert and produce a new cert that says citibank that also has the same signature. I was mentioning this because most people seem to think that this is what the attack involves.
But that is not th case in this attack. You don't need to create a cert that hase the same signature, just a cert for the same host signed by a trusted CA (and that is much worse). Anyway, you got the attack wrong. I think you may have understood that by now.
I think in your article you got this wrong. "That kind of attack doesn't seem like it's going to be practical in the next few years, though we should expect it will be possible sooner than later (developers: stop using MD5. Switch to something in the SHA family)." The CCC guys already created a CA cert with which they can sign any cert for any host they want. That cert, signed by that forged CA cert, will look legitimate to the client browser, because it looks like it is signed by a trusted CA. So, yes: the sky is falling.
I'm only concerned about the recommendation of the authors to do nothing if you've been issued an MD5 certificate yourself. Doing nothing does not seem to be a very good advice. I would myself go to another shop and get a SHA-1 signed certificate (or even a SHA-2 signed certificate for those not concerned with low level browsers). At least your customers will know that there is no man in the middle due to the MD5 issue, and you show that you care for your clients' security.
You can't really do anything about it. A man in the middle attack will always be possible. They generated a CA certificate, and with that cert they can sign self generated certs for every host they want, and the client browser will trust it. You, as a site owner, can't do anything about it. The attacker can spoof the dns response for www.bank.com, redirect the client to his own box with his own web server and valid certificate for www.bank.com and get all data the client sends him. As I sad, www.bank.com is not able to prevent anything in this case, even if they avoid the use of CAs that make use of MD5 for their certs.
I use svn because it makes no sense for me to use a distributed repository for my code. I keep my code on one server, I have my local working copy and I work on that. I use it mainly to see why or when I made a particular change and that's it, so I have no reason to switch to git.
I remember my first Mac had a 1,44" Floppy with a very cool tutorial app that illustraded the most important steps you had to do in order to get started: click to open an app, how drag&drop works, where the apps are located, how to save a document and how to open one. I was 15 years old, and I remember I very much enjoyed the little tutorial app, it was funny and helped me getting started quickly. I agree with you here: put a quick (max 15min) comic style tutorial app on the desktop, and people will have a different view on the whole thing, and like it more.
This is not about real paranoid people. The real paranoid people (like me) never trusted skype (encrypted, closed source binary blob). This news is for the non-tinfoil-hat people. Now they too know, like us paranoid people, that their conversations are tracked, recorded, monitored and archived. For real. And now they know, if they read and understand the news, that what skype sad to us all ('full end-to-end security is preserved and there is no compromise of people's privacy.') was a lie. Skype (eBay) lied, maybe one time, maybe on other, more important things too, and maybe they will do it again.
https certs, if implemented correctly, grant end to end encryption and authentication from one endpoint to another (usually your browser and the server you connect to): you know who you are talking to and the stuff you send is encrypted. dnssec, on the other hand, "guarantees" you, that the DNS entry of www.example.org you get back from the DNS server is unadulterated and legitimate. You are right with your assumption that dnssec doesn't add anything new: if https is implemented and used correctly, you are already "secure".
This game sounds absolutely perfect for the Wii. You've got an editor, which the Wii excels at with Wiimote pointing, and a platformer, which the Wii excels at with the Wiimote held sideways. This game is obviously catering to the Wii crowd.
That's true, but I bet they will use the Sixaxis capabilities for the level creation part. I agree with you, the Wiimote would be better, but I didn't see the game yet, maybe it's just as slick witth the DualShock as it would be with the Wiimote.
But the main purpose of the game is content creation, right? So obviously you'd want a console with great online community support, which the Wii doesn't quite have. So that aspect is perfect for the Xbox 360 then!
What is wrong with the PS3 online support? I am playing resistance online quite a lot, and there is absolutely no lag or other annoyances. The only thing that works better on Xbox live is the voice chat, but I can live without that, and I am sure sony will fix it soner or later.
It really looks like you are angry because you would enjoy this game but can't/won't afford a PS3.
Excellent point. This is a very silly way to 'protest' about DRM. The best way to get companies to stop using DRM is to reason with them, contact them, and let them know how you feel.
localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.
[Citation needed] Webkit has a HTML5 compliant local storage api since Friday, October 19th, 2007. So, if they branched Webkit in January 2008 as you state, the implementation was already there. But anyway, can you backup your statement with some links?
The webkit implementation in Chrome right now is over a year out of date...
No conspiracy theory here. Wait for Google to update the current webkit version.
Wabkit has the local storage api in place since Friday, October 19th, that's a pretty long time for a HTML rendering engine, and without backporting stuff to their local implementation. No conspiracy theory here: companies pushing their own stuff over standard implementations is pretty normal stuff.
I see no reason not to assume stupidity instead of malice.
I do actually. The HTML 5 compatible client side storage API was lready there. To remove it, they HAD to know it is there. So they stripped it out and replaced it whit google gears. No stupidity there. Any other excuses?
Do you have an explanation then why they included google gears instead of Webkits HTML 5 api? Really, just asking. The only reason I can think of is that they want to push their own implementation, but I would gladly be corrected. Now, as it stands, web developers who want to use local, client side storage have to test for google gears AND for the webkit api, yet another fragmentation. Looks just like ie6 all over again to me, but as I sad, pleas correct me if I am wrong.
So google stripped the HTML 5 standard local storage api from Webkit to use their own implementation Google Gears. Why? The api was already there, and it worked, so they had to strip it out to go with google gears, their own, not w3c compliant. I think they are starting to become evil.
I posted this earlier today, but I feel I have to post this again, as it is really important people know what they get in to using this browser:
In metrics_service.cc [chromium.org] it sends everything you do in the toolbar to static const char kMetricsURL[] =
"https://toolbarqueries.google.com/firefox/metrics/collect"; It collects everything and sends it to google servers, on startup and on shutdown.
// Ongoing log typically // contain very detailed records of user activities (ex: opened tab, closed // tab, fetched URL, maximized window, etc.) In addition, just before an // ongoing log is closed out, a call is made to gather memory statistics. Those // memory statistics are deposited into a histogram, and the log finalization // code is then called. In the finalization, a call to a Histogram server // acquires a list of all local histograms that have been flagged for upload // to the UMA server. // // When the browser shuts down, there will typically be a fragment of an ongoing // log that has not yet been transmitted. At shutdown time, that fragment // is closed (including snapshotting histograms), and converted to text. Note // that memory stats are not gathered during shutdown, as gathering *might* be // too time consuming. The textual representation of the fragment of the // ongoing log is then stored persistently as a string in the PrefServices, for // potential transmission during a future run of the product.
WHAT THE FUCK. Keep ff ftw. If your privacy means nothing to you just use Chrome.
Slashdot Mirror
I don't think banks will be using MD5 at this point in time.
That is not important. CAs that use MD5 for their cert signing are already in the browsers list of trusted CAs. It is not important what CA the banks use for their own certs for this attack to work.
I was talking about finding a new cert where the signature matches any arbitrary web site cert. That is, you can't take Citibank's cert and produce a new cert that says citibank that also has the same signature. I was mentioning this because most people seem to think that this is what the attack involves.
But that is not th case in this attack. You don't need to create a cert that hase the same signature, just a cert for the same host signed by a trusted CA (and that is much worse). Anyway, you got the attack wrong. I think you may have understood that by now.
I think in your article you got this wrong. "That kind of attack doesn't seem like it's going to be practical in the next few years, though we should expect it will be possible sooner than later (developers: stop using MD5. Switch to something in the SHA family)."
The CCC guys already created a CA cert with which they can sign any cert for any host they want. That cert, signed by that forged CA cert, will look legitimate to the client browser, because it looks like it is signed by a trusted CA. So, yes: the sky is falling.
I'm only concerned about the recommendation of the authors to do nothing if you've been issued an MD5 certificate yourself. Doing nothing does not seem to be a very good advice. I would myself go to another shop and get a SHA-1 signed certificate (or even a SHA-2 signed certificate for those not concerned with low level browsers). At least your customers will know that there is no man in the middle due to the MD5 issue, and you show that you care for your clients' security.
You can't really do anything about it. A man in the middle attack will always be possible. They generated a CA certificate, and with that cert they can sign self generated certs for every host they want, and the client browser will trust it. You, as a site owner, can't do anything about it. The attacker can spoof the dns response for www.bank.com, redirect the client to his own box with his own web server and valid certificate for www.bank.com and get all data the client sends him. As I sad, www.bank.com is not able to prevent anything in this case, even if they avoid the use of CAs that make use of MD5 for their certs.
haha :) but they took mine! :)
Yes.
Many non-power-users don't use addons at all.
Everybody (well, almost of course) has flash installed nowadays.
I use svn because it makes no sense for me to use a distributed repository for my code. I keep my code on one server, I have my local working copy and I work on that. I use it mainly to see why or when I made a particular change and that's it, so I have no reason to switch to git.
http://i36.tinypic.com/2ir6oah.jpg
Yes.
I remember my first Mac had a 1,44" Floppy with a very cool tutorial app that illustraded the most important steps you had to do in order to get started: click to open an app, how drag&drop works, where the apps are located, how to save a document and how to open one. I was 15 years old, and I remember I very much enjoyed the little tutorial app, it was funny and helped me getting started quickly. I agree with you here: put a quick (max 15min) comic style tutorial app on the desktop, and people will have a different view on the whole thing, and like it more.
This is not about real paranoid people. The real paranoid people (like me) never trusted skype (encrypted, closed source binary blob).
This news is for the non-tinfoil-hat people. Now they too know, like us paranoid people, that their conversations are tracked, recorded, monitored and archived. For real. And now they know, if they read and understand the news, that what skype sad to us all ('full end-to-end security is preserved and there is no compromise of people's privacy.') was a lie. Skype (eBay) lied, maybe one time, maybe on other, more important things too, and maybe they will do it again.
https certs, if implemented correctly, grant end to end encryption and authentication from one endpoint to another (usually your browser and the server you connect to): you know who you are talking to and the stuff you send is encrypted.
dnssec, on the other hand, "guarantees" you, that the DNS entry of www.example.org you get back from the DNS server is unadulterated and legitimate.
You are right with your assumption that dnssec doesn't add anything new: if https is implemented and used correctly, you are already "secure".
lol :) :) That's why I mute everybody right on the start of the game, problem solved :)
I agree
This game sounds absolutely perfect for the Wii. You've got an editor, which the Wii excels at with Wiimote pointing, and a platformer, which the Wii excels at with the Wiimote held sideways. This game is obviously catering to the Wii crowd.
That's true, but I bet they will use the Sixaxis capabilities for the level creation part. I agree with you, the Wiimote would be better, but I didn't see the game yet, maybe it's just as slick witth the DualShock as it would be with the Wiimote.
But the main purpose of the game is content creation, right? So obviously you'd want a console with great online community support, which the Wii doesn't quite have. So that aspect is perfect for the Xbox 360 then!
What is wrong with the PS3 online support? I am playing resistance online quite a lot, and there is absolutely no lag or other annoyances. The only thing that works better on Xbox live is the voice chat, but I can live without that, and I am sure sony will fix it soner or later.
It really looks like you are angry because you would enjoy this game but can't/won't afford a PS3.
http://www.mininova.org/search/?search=asus
Very insightful. Thanks for this beautiful post.
Excellent point. This is a very silly way to 'protest' about DRM. The best way to get companies to stop using DRM is to reason with them, contact them, and let them know how you feel.
So, how are your sales going now?
localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.
[Citation needed]
Webkit has a HTML5 compliant local storage api since Friday, October 19th, 2007. So, if they branched Webkit in January 2008 as you state, the implementation was already there. But anyway, can you backup your statement with some links?
The webkit implementation in Chrome right now is over a year out of date...
No conspiracy theory here. Wait for Google to update the current webkit version.
Wabkit has the local storage api in place since Friday, October 19th, that's a pretty long time for a HTML rendering engine, and without backporting stuff to their local implementation.
No conspiracy theory here: companies pushing their own stuff over standard implementations is pretty normal stuff.
No, I don't care that much (at least until Chrome remains at 1%), and it looks very much self-explanatory to me.
I see no reason not to assume stupidity instead of malice.
I do actually. The HTML 5 compatible client side storage API was lready there. To remove it, they HAD to know it is there. So they stripped it out and replaced it whit google gears. No stupidity there. Any other excuses?
Do you have an explanation then why they included google gears instead of Webkits HTML 5 api? Really, just asking. The only reason I can think of is that they want to push their own implementation, but I would gladly be corrected.
Now, as it stands, web developers who want to use local, client side storage have to test for google gears AND for the webkit api, yet another fragmentation. Looks just like ie6 all over again to me, but as I sad, pleas correct me if I am wrong.
So google stripped the HTML 5 standard local storage api from Webkit to use their own implementation Google Gears. Why? The api was already there, and it worked, so they had to strip it out to go with google gears, their own, not w3c compliant. I think they are starting to become evil.
I posted this earlier today, but I feel I have to post this again, as it is really important people know what they get in to using this browser:
In metrics_service.cc [chromium.org]
it sends everything you do in the toolbar to
static const char kMetricsURL[] =
"https://toolbarqueries.google.com/firefox/metrics/collect";
It collects everything and sends it to google servers, on startup and on shutdown.
WHAT THE FUCK. Keep ff ftw.
If your privacy means nothing to you just use Chrome.