[tickerguy]

Sorry, disagree.

If the server you connect to will not take a connection with said weak keying it doesn't matter if the browser will allow the downgrade as the connection will not negotiate and thus the attack is worthless.

This IS a serious issue for webmasters with server configurations that allow weak keying -- but anyone still allowing that in the "free" part of the world is nuts and deserves to be spanked to start with.

Posted via CB10

[Richard Buckley]

Sorry, disagree.

If the server you connect to will not take a connection with said weak keying it doesn't matter if the browser will allow the downgrade as the connection will not negotiate and thus the attack is worthless.

This IS a serious issue for webmasters with server configurations that allow weak keying -- but anyone still allowing that in the "free" part of the world is nuts and deserves to be spanked to start with.

Posted via CB10

Did you even read Matthew Green's article? He is a cryptographer and research professor at Johns Hopkins University. He has been involved co-ordinating the disclosure of FREAK. This is how he describes the attack:

The MITM attack works as follows:

* In the client's Hello message, it asks for a standard 'RSA' ciphersuite.
* The MITM attacker changes this message to ask for 'export RSA'.
* The server responds with a 512-bit export RSA key, signed with its long-term key.
* The client accepts this weak key due to the OpenSSL/SecureTransport bug.
* The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
* When the client encrypts the 'pre-master secret' to the server, the attacker can now decrypt it to recover the TLS 'master secret'.
* From here on out, the attacker sees plaintext and can inject anything it wants.

[dguy123]

Yes, definitely.

We'll send smoke signals when it�s safe to come back.

Posted via CB10

[tickerguy]

Yeah, Richard, I read it.

Try it against my server and it will fail because when you try to downgrade my server will erect the middle finger and SSL negotiation fails.

That's why it DOES NOT MATTER against a properly-configured server.

I've been doing this stuff for a living since the 1990s.. this is a real problem but only against servers either intentionally or unintentionally configured to accept weak keying.

Posted via CB10

[Raestloz]

Did you even read Matthew Green's article? He is a cryptographer and research professor at Johns Hopkins University. He has been involved co-ordinating the disclosure of FREAK. This is how he describes the attack:

It seems that the problem is not that the client allows weak encryption, it's that the server is willing to

This seems to be a problem in both sides, servers will be forced to upgrade if no client can connect to it, and vice versa, but it seems that servers have to start the change

Z10STL100-1/10.3.1.2243

[Richard Buckley]

Yeah, Richard, I read it.

Try it against my server and it will fail because when you try to downgrade my server will erect the middle finger and SSL negotiation fails.

That's why it DOES NOT MATTER against a properly-configured server.

I've been doing this stuff for a living since the 1990s.. this is a real problem but only against servers either intentionally or unintentionally configured to accept weak keying.

Posted via CB10

Yes, the server does need to be configured to accept a weak key. That is clearly stated in the vulnerability description, and why they spend so much effort to enumerate servers that have weak keys configured. For some servers this may be simple laziness, but for others it may be a deliberate choice to serve those people with clients that can't get strong cryptography.

My servers aren't vulnerable either. In fact, because I have enabled Strict Transport Security, only accept unencrypted connections to forward them to an encrypted connection, and only support strong keys with forward secrecy anyone still using XP (or weak keys only) can't use my site.

But what if the purpose of my site was to provide information, not just to people who live in free countries who have access to strong encryption, but also to people who only have weak keys because they live under oppressive regimes, as you brought up. I can allow them to access the site unencrypted, or support weak keys to provide some limited protection. If all browsers work properly the obvious solution is the latter. Browsers with only weak cryptography get a weak connection, for whatever good that may do. But browsers with strong encryption get a strong connection and it is all good.

That is its all good until someone gets into the middle of the connection. A strong browser initiates a connection to a server with both strong and weak keys asking for only strong encryption. The MiM intercepts and modifies the request to ask for export grade weak keys. The server has no opportunity to know that the resulting request is not a legitimate one from a browser that only supports weak keys, and responds accordingly. What the browser is supposed to do is check the reply to ensure that it contains only choices that it asked for. A browser that isn't vulnerable would stick up a finger to the MiM saying that the offered connection wasn't asked for and drop the circuit. A browser that isn't vulnerable probably just passes the reply to the cryptography library without looking at it. Since all library still support all key sizes a connection is established that the MiM can decrypt.

Sure, browser administrators can abandon weak cryptography and let the devil take the hind most, as we have. But some, probably not all but certainly some, may be required to give access to people who can't, or won't get modern cryptography. If browsers behaved properly this wouldn't be a problem. Browsers should not tell servers they will accept A, B and C but take D because that is all they are offered.

Server admins can protect their users by not having unnecessary weak suites available, as you and I have done. But browsers need to protect themselves by implementing the protocol correctly for when they visit sites that are not well managed or are required to support export grade keys for some reason.

Z10STL100-3/10.3.1.2072

[tickerguy]

Yes and no.

If a server admin has to provide weak-key service for some reason (e.g. he wants to allow "encrypted" connections to people in places that prohibit strong crypto) then such a connection is always open to the potential for interception via this method.

The problem with ranting about BlackBerry's browser is that it is in a mobile device. That is, prohibiting it from connecting while using a weak key (that the server accepted) will mean in those jurisdictions no encryption is available to that person at all. That is, in my opinion, a net negative.

Let me tell you a little story -- there's a somewhat-similar problem with SSL3, except that it really IS broken as opposed to just being able to be factored. Browser makers have been shutting off access to it entirely; Chrome, Firefox and recent versions of IE will refuse to connect to a site that demands it as a cipher. Well, that's nice, except for one issue -- there are some embedded devices that only have SSL3 crypto available at all. So guess what -- now there's nothing available for them period in terms of web management!

Is this better? Well, it would be nice if the firmware had an upgrade to resolve this, but not all do. Now what? That so-called "remote management" has just been quite-effectively removed from that device entirely for legitimate users however the attack vector remains for those who wish to come at it in a malicious fashion.

In other words not only did that "choice" by the browser folks cost the user functionality (in that now you can't talk to it at all!) it did exactly nothing to mitigate the risk of the device being penetrated.

Bringing up a warning that an insecure path has been elected is one thing, but to entirely block it is another and in some cases, such as this, does harm​.

[Richard Buckley]

Yes and no.

If a server admin has to provide weak-key service for some reason (e.g. he wants to allow "encrypted" connections to people in places that prohibit strong crypto) then such a connection is always open to the potential for interception via this method.

The problem with ranting about BlackBerry's browser is that it is in a mobile device. That is, prohibiting it from connecting while using a weak key (that the server accepted) will mean in those jurisdictions no encryption is available to that person at all. That is, in my opinion, a net negative.

Let me tell you a little story -- there's a somewhat-similar problem with SSL3, except that it really IS broken as opposed to just being able to be factored. Browser makers have been shutting off access to it entirely; Chrome, Firefox and recent versions of IE will refuse to connect to a site that demands it as a cipher. Well, that's nice, except for one issue -- there are some embedded devices that only have SSL3 crypto available at all. So guess what -- now there's nothing available for them period in terms of web management!

Is this better? Well, it would be nice if the firmware had an upgrade to resolve this, but not all do. Now what? That so-called "remote management" has just been quite-effectively removed from that device entirely for legitimate users however the attack vector remains for those who wish to come at it in a malicious fashion.

In other words not only did that "choice" by the browser folks cost the user functionality (in that now you can't talk to it at all!) it did exactly nothing to mitigate the risk of the device being penetrated.

Bringing up a warning that an insecure path has been elected is one thing, but to entirely block it is another and in some cases, such as this, does harm​.

But this is not what is being discussed, preventing browsers from asking for export grade keys, at least not by those who found the vulnerability. This is plain in the warning "Your browser is vulnerable to the FREAK attack. It can be tricked into using weak encryption..." if the browser requests export grade cipher and the server supports it then that is what should be provided. And yes, it will be vulnerable to strait up intercept, and MiM modifications.

But if a browser has been configured not to ask for export grade cipher then it should not accept it. If this is not corrected now we will go through all of this again the next time someone finds a flaw in an old cipher suite.

On the other hand I totally agree with your pragmatic approach. What I find really concerning is not that the BlackBerry Browser, or any other browsers are vulnerable. That will be fixed, too slowly for some people but it will be.

No, what really worries me is that Microsoft and Google have put effort into retiring SHA1. Google is being positively rabid about it. But neither have looked to their own house to fix the downgrade bug. Neither have BlackBerry nor Apple, but neither are these two pontificating on what people should or should not use for cipher. Don't get me wrong, the time has certainly come to start working on moving on from SHA1 and other long in the tooth cryptography. But Google's move it or loose it stance could arguably be better aimed at fixing vulnerabilities in the Android install base.

Z10STL100-3/10.3.1.2072

[Deckard79]

Subscribed.

The most interesting thing for me will be how a company that purports to prioritise security more than competitors actually handles this.

Will we have this vulnerability whilst Microsoft/Android devices are patched?

Posted via CB10

[Richard Buckley]

Unfortunately as bad as FREAK is, it hold a candle to not checking to see if a certificate has been revoked.

Try to connect to this page: https://revoked.grc.com

If you can your browser is not checking to see if a sites certificate has been revoked. The test is described here: https://www.grc.com/revocation.htm

If it is any consolation, my iPad is also does not check for revoked certificates. Crome has blacklisted that particular certificate, so you won't be able to load the page on a Crome browser. But Crome doesn't actually check revokation lists. There is some debate as to whether this is a better way or not:
https://www.grc.com/revocation/crlsets.htm
Chrome does certificate revocation better | ZDNet

The real issue that we should be concerned with is not the latest hotness in exploits making the rounds of news sites. The whole "web of trust" that is supposed to secure the World Wide Web is fundamentally broken.

[tufcustomer]

You're an ***** companies offer a bounty when you give them an opportunity to respond to a security bug and fix. Facebook recently paid �8000 to a developer who discovered a piece of code could delete photos forever.

Posted via CB10

Interesting, I guess that delete button doesn't do what it's supposed to then if Facebook considers this a bug. I know nothing on the Internet is ever gone for good but the fact that they paid him for this. Smh.

Posted via CB10

[kbz1960]

Unfortunately as bad as FREAK is, it hold a candle to not checking to see if a certificate has been revoked.

Try to connect to this page: https://revoked.grc.com

If you can your browser is not checking to see if a sites certificate has been revoked. The test is described here: https://www.grc.com/revocation.htm

If it is any consolation, my iPad is also does not check for revoked certificates. Crome has blacklisted that particular certificate, so you won't be able to load the page on a Crome browser. But Crome doesn't actually check revokation lists. There is some debate as to whether this is a better way or not:
https://www.grc.com/revocation/crlsets.htm
Chrome does certificate revocation better | ZDNet

The real issue that we should be concerned with is not the latest hotness in exploits making the rounds of news sites. The whole "web of trust" that is supposed to secure the World Wide Web is fundamentally broken.

Opera on win10 preview says the certificate has been revoked.

[conite]

Subscribed.

The most interesting thing for me will be how a company that purports to prioritise security more than competitors actually handles this.

Will we have this vulnerability whilst Microsoft/Android devices are patched?

Posted via CB10

Apparently it's been fixed in 10.3.1.2558. Whitelisted testers are getting it now.

Z30STA100-5/10.3.1.2267

[Ment]

Opera on win10 preview says the certificate has been revoked.

I'm assuming that because Opera uses the same engine Blink as Chrome they are using the same revocation blacklist method?

[Maxxxpower]

iOS 8.2 fixed FREAK vulnerability. "Security" company Blackberrys OS is still vulnerable.

[Richard Buckley]

iOS 8.2 fixed FREAK vulnerability. "Security" company Blackberrys OS is still vulnerable.

Speed is not always a virtue when fixing security problems. Remember HeartBleed, and GOTO Fail.

The 8.2 update is more than just a fix for FREAK. As is the update being tested now, as reported above.

Z10STL100-3/10.3.1.2072

[anon(6038817)]

Apple released patches for iOS and Mac OS X as of yesterday. Windows released patches for Desktop versions of Windows today (Windows phones are likely still vulnerable).

But my best-in-class-for-security-and-privacy BlackBerry is still vulnerable. Oh, the irony.

And it's not like BB can just issue a patch worldwide like Apple can. In North America, they would have to go through the carriers to push an OS update. Most BB users in NA who bought their phones through a carrier are still waiting on 10.3.1 to drop.

I'm sorry, but I'm becoming a bit disillusioned with BlackBerry's "privacy and security" claims. (To say nothing of the fact that most BB security features are useless anyway unless the phone is paired with a BES.)

All I know is, my Q10 is vulnerable to FREAK, and iPhones are not. That's not a good feeling.

[muindor]

Apple released patches for iOS and Mac OS X as of yesterday. Windows released patches for Desktop versions of Windows today (Windows phones are likely still vulnerable).

But my best-in-class-for-security-and-privacy BlackBerry is still vulnerable. Oh, the irony.

And it's not like BB can just issue a patch worldwide like Apple can. In North America, they would have to go through the carriers to push an OS update. Most BB users in NA who bought their phones through a carrier are still waiting on 10.3.1 to drop.

I'm sorry, but I'm becoming a bit disillusioned with BlackBerry's "privacy and security" claims. (To say nothing of the fact that most BB security features are useless anyway unless the phone is paired with a BES.)

All I know is, my Q10 is vulnerable to FREAK, and iPhones are not. That's not a good feeling.

From the view of a Quality manager this post is the best feedback a company can get. I wish BlackBerry would read this. In this forum there are so many amazing people giving the best suggestions/impressions, because they (including me) think BlackBerry is good and we want it to survive and get better, and that more people should get a BlackBerry as a better choice of devices.
BlackBerry just needs to use this feedback to improve themselves.



[Richard Buckley]

From the view of a Quality manager this post is the best feedback a company can get. I wish BlackBerry would read this. In this forum there are so many amazing people giving the best suggestions/impressions, because they (including me) think BlackBerry is good and we want it to survive and get better, and that more people should get a BlackBerry as a better choice of devices.
BlackBerry just needs to use this feedback to improve themselves.



All software has flaws. Software is designed, written and tested by people. It is ment to be used by people who want features and convenience. Features and convenience are the enemy of security. Security is the enemy of features and convenience. There may come a day when a group of people will be able to write flawless software that will be feature rich, convenient to use and completely secure. But that is not today. In the world we live and work in data security and privacy depends on a defence in depth so that one single flaw does not cause a complete collapse. FREAK is a good example of this.

The flaw has probably been in the browser since web kit was first released, but there is no evidence either before or after publication that it is being used in the wild. In all these years no one found it, until now. That is disappointing, but other vulnerabilities, that were much worse, have been around for much longer. ShellShock for example. If you look at what it would take for someone to be able to exploit FREAK you will probably come to the conclusion that there are much easier ways to attack mobile devices to get access to the same data. That's probably why FREAK hasn't yet been seen in the wild.

BlackBerry will release a patch. Microsoft will eventually patch everything to. Not as quickly as others. Not as quickly as we would like. But is this the yard stick you want to judge the security of your mobile device by? I look at the number of people who have lost personal data from other platforms that have caused them real harm and then look at BlackBerry. It is not realistic to expect any platform to be flawless. You will never know where the next flaw is going to be found, or what impact it is going to have. Everyone is entitled to take what ever lesson from this they want to. If using equipment that is first to be patched makes you more comfortable about your security or privacy, then by all means go with the product that is patched the fastest. I'm going to be sticking with the product that has the best record against real loss. But that's just my choice.

[Maxxxpower]

I'm sorry, but I'm becoming a bit disillusioned with BlackBerry's "privacy and security" claims. (To say nothing of the fact that most BB security features are useless anyway unless the phone is paired with a BES.)

Exactly. Security features only for subscribers is one of the main flaw of Blackberry devices. Every customer should get all the security features that don't depend on a management server, especially BBM Protected and Balance.

[Richard Buckley]

Exactly. Security features only for subscribers is one of the main flaw of Blackberry devices. Every customer should get all the security features that don't depend on a management server, especially BBM Protected and Balance.

Balance is only an effective security feature if there is someone to manage the hundreds of configuration options, and who has the knowledge to choose the appropriate configuration for the threat faced. And when it comes right down to it Balance doesn't enhance security. It is a controlled way of relaxing the security of a BES one a partition of the device.

BBM Protected needs a centralized way of controlling and protecting the PKI key pairs. There has been a free public key email system with self managed keys around for decades. Snowden wanted to use it to communicate with reporters but it was "too complicated" for them to use. The program was only just saved from oblivion of underfunding. Almost no one uses it.

Since you want these features for free you have no doubt used BlackBerry Unite, BES Express and the free BES 10 cloud solution. So you know that with each of these someone had to mange the service.

There is a cost to BlackBerry to provide these services. They can provide them on a subscription basis so users have the choice of using them (and paying for them), and the period of time they want to use them. Or they could build the cost into the cost of the device so everyone pays for them whether they use them or not.

Z10STL100-3/10.3.1.2072

[Maxxxpower]

Balance (or a comparable solution) would be useful for non-BES users to get an environment to use Android apps which don't support the permission manager (I know there are third party apps for this). One could simply not store any personal data in that "second part" of the OS so that the apps wouldn't be able to access any personal data.

Regarding BBM Protected: As it is usable for non-BES users it would not be a problem to provide it to anybody. Other IMs like Whatsapp and iMessage or even smaller IMs support end-to-end encryption, so why not BBs IM? Isn't BB all about security? As the other IMs are able to implement the encryption so that it is usable any user, BB should be able to do the same.

Even S/MIME and PGP is (at least until 10.3.2 arrives) aren't unlocked for non-BES users.

All this feature crippling seems to me like a bad joke and won't help BB to regain any market share as other mobile OSes will provide them or are providing them for free.

"Security" company. LOL. Better company trying to survive by selling stickers and custom PINs instead of bringing important security and privacy features to the customers or fixing known security flaws.

[anon(6038817)]

Balance (or a comparable solution) would be useful for non-BES users to get an environment to use Android apps which don't support the permission manager (I know there are third party apps for this). One could simply not store any personal data in that "second part" of the OS so that the apps wouldn't be able to access any personal data.

Regarding BBM Protected: As it is usable for non-BES users it would not be a problem to provide it to anybody. Other IMs like Whatsapp and iMessage or even smaller IMs support end-to-end encryption, so why not BBs IM? Isn't BB all about security? As the other IMs are able to implement the encryption so that it is usable any user, BB should be able to do the same.

Even S/MIME and PGP is (at least until 10.3.2 arrives) aren't unlocked for non-BES users.

All this feature crippling seems to me like a bad joke and won't help BB to regain any market share as other mobile OSes will provide them or are providing them for free.

"Security" company. LOL. Better company trying to survive by selling stickers and custom PINs instead of bringing important security and privacy features to the customers or fixing known security flaws.

Excellent points. I couldn't agree more. WhatsApp, for all its flaws, supports end to end encryption. iMessages also. BBM? Not without a BES.

BB phones have a lot going for them, but for the non-business customer like me, can they really claim the security and privacy crown?

[Richard Buckley]

Excellent points. I couldn't agree more. WhatsApp, for all its flaws, supports end to end encryption. iMessages also. BBM? Not without a BES.

BB phones have a lot going for them, but for the non-business customer like me, can they really claim the security and privacy crown?

I haven't looked at WhatsApp, but iMessage is only end to end encryption in that they don't decrypt messages, not that they can't. Apple manages the keys, and tells iMessage which public keys to use for encryption. They can at any time add any key they want, one for the FBI for example. They say that they can't, I believe that they aren't, but if the US government forces them to implement key escrow they can do it.

With BES and BBM Protected BlackBerry doesn't have the keys. They are managed, and can be created by the BES administrator. Since BlackBerry never has the keys they can't provide them even if forced.

If you really need end to end encryption you probably need the kind BlackBerry provides and are willing to pay for it.

Z10STL100-3/10.3.1.2072

[Maxxxpower]

When using BBM Protected without BES, there's no key management by users, too, isn't it?
Even without key management, end-to-end encryption would be a huge step forwared compared to the scrampling thing BBM provides at the moment.