[anon(6038817)]

What exactly is your idea of "good time"? It's all relative in that Apple came out with a release first. We all know they do **** poor testing.

In this case, Apple quickly and successfully patched the vulnerability before anyone else did. I'm not sure what that has to do with testing.

But if you want to talk about testing, why did BlackBerry have to halt the 10.3.1 roll-out, again? Because of widespread reports of bugs.

Look, I'm a BlackBerry fan, but I'm not so blinded by my fandom that I have to make up ridiculous excuses for them when they screw up. And this is a pretty big screw-up in my book.

[Deckard79]

Not patched yet then... if this is true:

https://threatpost.com/blackberry-wa...-attack/111607


Posted via CB10

[anon(6038817)]

Not patched yet then... if this is true:

https://threatpost.com/blackberry-wa...-attack/111607


Posted via CB10

And they took a week to even acknowledge this. Pretty sad.

[dvarnai]

KB36811-BlackBerry response to OpenSSL "FREAK" Vulnerability

Affected Software
...
Secure Work Space for BES10/BES12 (Android) (all versions)
BBM Protected on BlackBerry 10 and BlackBerry OS (all versions)
BBM Protected on Android earlier than version 2.7.0.6
BBM Protected on iOS earlier than version 2.7.0.32
...

[BCITMike]

In this case, Apple quickly and successfully patched the vulnerability before anyone else did. I'm not sure what that has to do with testing.

But if you want to talk about testing, why did BlackBerry have to halt the 10.3.1 roll-out, again? Because of widespread reports of bugs.

Look, I'm a BlackBerry fan, but I'm not so blinded by my fandom that I have to make up ridiculous excuses for them when they screw up. And this is a pretty big screw-up in my book.

And 10.3.1 had what security bugs that caused the issues? Right, non-security bugs. BlackBerry didn't have an epic fail like "goto fail", which to this day, still doesn't have a valid explanation as to how this bug got added and missed for so long (patch failure excuse is ridiculous), and why the fix took 4+ months after notification. I mean, gotofail is much faster to exploit than this bug. After Apple has dropped the ball on epic scale the last year or so on security, they NEED to be releasing updates faster than other vendors.

Because I work in the real world, dealing with large enterprises and not on emotion and wants. Enterprises hate pushed/forced updates and admins feel like its THEIR network, they get to choose when updates occur. Many things in the real world operate where large enterprises are on the not-so-recent OS's and releases and leave the latest stuff that breaks to consumers and power users. So back when BlackBerry started a decade ago rolled out updates without wifi, the providers were on the hook for all bandwidth, support, customer interfacing issues, etc. It takes co-operation to coordinate updates. They have longer support cycles than consumer targeted services. It was easier for Apple to demand this, given that Jobs does less co-operation and more 'this is how its done, take it or leave it'. It also means that more people upgrade iPhones more often, making money for providers. Not everyone is an ahole like Jobs, which is probably what BB needs to do if they want to circumvent providers. I'm not defending it, I'm just saying its more complex than what you guys are assuming. You can say its old, outdated, but you can't say "no reason". There are reasons.

At this time, BlackBerry is in the middle of releasing 10.3.1, which had issues upon release. This mean their QA group is tied up with those issues, and they have a user base stuck between 10.2 and 10.3.1. They can stop working on the 10.3.1 and push out fixes for 10.2.1 and 10.3.1 ONLY, which may or may not exacerbate the upgrade issues, or they can say, "we'll take some extra few days and just roll it into 10.3.1.x and force everyone to update". Here is a list of the products that BlackBerry had to test and verify before publicly responding:

BlackBerry 10 OS (all versions)
BlackBerry 7.1 OS and earlier (all versions)
BES12 (all versions)
BES10 (all versions)
BES12 Client (iOS) (all versions)
Secure Work Space for BES10/BES12 (Android) (all versions)
Work Space Manager for BES10/BES12 (Android) (all versions)
Work Browser for BES10/BES12 (iOS) (all versions)
Work Connect for BES10/BES12 (iOS) (all versions)
BlackBerry Blend for BlackBerry 10, Android, iOS, Windows and Mac (all versions)
BlackBerry Link for Windows and Mac (all versions)
BBM on BlackBerry 10 and Windows Phone (all versions)
BBM on Android earlier than version 2.7.0.6
BBM on iOS earlier than version 2.7.0.32
BBM Protected on BlackBerry 10 and BlackBerry OS (all versions)
BBM Protected on Android earlier than version 2.7.0.6
BBM Protected on iOS earlier than version 2.7.0.32
BBM Meetings for BlackBerry 10, Android, iOS, and Windows Phone (all versions)

That is a lot to go through. You need to research the flaw, setup test benches, test for possible workarounds, have proper tools for verifying the bug and the fix, etc. Plan how to release things, etc. How big was Apple's test? 3 OS X's, 1 iOS 8.2, and one Apple TV update? Was Apple's priorities high because they were also fixing other vulnerabilities at the same time?

My experience is that after a major blindside, you're scrambling to quickly get answers to the people above you so they can make the best decisions. Sometimes those responses from R&D change every few hours. "We're looking into it." "We think everything is affected". "We think this might prevent it" "We think this might workaround it", etc. Upper management makes a comment when they feel like they understand where they stand.

Do I think it would be better to have instantaneous security fixes? Yes.
Do I think it would be better to have updates before anyone else? Yes.
Do I think its honestly possible to ALWAYS be the first to release security fixes, regardless of impact and severity? No.

What would tick me off, would be if BlackBerry was notified 3 months ago about this, and this is the state after 3 months. I don't really know when each vendor was notified. But under 2 weeks is not ticking me off, 3 months would. I don't know where the line is in between that to be "reasonable" response or not.

[dvarnai]

fun fact, ive tried a firefox today back from last september and it wasnt vulnerable...

[anon(6038817)]

[BCITMike]

In this case, Apple quickly and successfully patched the vulnerability before anyone else did. I'm not sure what that has to do with testing.

But if you want to talk about testing, why did BlackBerry have to halt the 10.3.1 roll-out, again? Because of widespread reports of bugs.

Look, I'm a BlackBerry fan, but I'm not so blinded by my fandom that I have to make up ridiculous excuses for them when they screw up. And this is a pretty big screw-up in my book.

Because sometimes the first patch doesn't actually fix the problem, sometimes the problem isn't fully understood well enough to be properly patched. On the Bash vulnerability, there were several patches, because the conditions to test/check would expand as more testers got involved and found more use cases that were vulnerable. There was 1 bash check, then there was 6 or 7 the following week. Then there were systems that would be patched, say its no longer vulnerable, but were actually vulnerable until the server was rebooted. These are caused by poor testing tools. It takes time to make testing tools that work right.

You can't always rush out a fix. It really depends on the extent of the issue. For example, to fix the Apple goto fail bug, would have been 1 line of change and would restore it back the way it worked for years. When you are fixing something back to how it worked, there is less regression testing needed and low risk complications and that should not have taken 4 months to fix. But when a new bug can change how regular operation works, you need to expand your testing considerably. Or, making sure that that newly discovered type of attack, can't be used in a slightly different way.

[Richard Buckley]

Do you get the huge difference in security between TLS (Transport Layer Security) and an end-to-end encryption various other IMs are offering?

For me there is essentially no difference, I'll explain why I take that view below. You can disagree with all my arguments if you wish, but if you do my recommendation to you would be to either pay for a BES or switch to a platform that provides the level and type of security you are looking for. Apple or Windows are not bad choices. They have both certainly come a long way in mobile security. I prefer BlackBerry and I will tell you why. But the text that follows is only for the reason I don't see a huge difference. For responses to the rest of your post see below the next quote block.

End to end encryption can be a great boost in security, and if you need the highest communications security that is what you should strive for. But I see this is not a one or the other situation, but three different levels. For the sake of the argument, and rather than comparing differnent real products for the moment lets asume that the cryptography used in each case is the very best possible. Totally bug free, no back doors, very strong keys and random number generators. I'm not saying anyone acutually has this, but let's pretend everyone does.

So the three cases are:
1) Traffic is encrypted between each mobile device and the server. The time it is spent in server being routed, or stored until the destination is available the traffic is not encrypted. This is similar to the way email is handled between two subscribers on the same web mail provider that does not encrypt data on their server. The subscribers, lets use the classic crypto name Alice and Bob. Alice and Bob both connect to the server using TLS. No one can intercept or MiM their connections because they have perfect cryptography. But their messages are available to the provider Charlie, and anyone who can convince or coerce the provider to co-operate with them. Charlie could be completely honest, but he would still have to respond to a legal demand for Bob and Alices's messages in what ever jurisdiction Charlie occupied. For most users this is fine, for some it is not. So lets look at end-to-end encryption, that should be much better.

The next two have some common features. If Alice is sending a message to Bob, she obtains Bob's public key and encrypts the message with it. If she wants to she can sign the message with her private key so that Bob can verify that she was the originator. To do this he needs her public key. Since their crypto is strong, and bug free no one can read, or even tamper with their messages, right? The answer to that depends on how the public keys are handled.

2) In this case Bob and Alice aren't cryptographers, they are't even very computer literate. They can use their smart phones but they don't really understand them. But that's OK becuase the both feel that Charlie is honest, and Charlie has told them he has this great new communications tool that will encrypt the message on Alice's phone and it won't be decrypted until it reaches Bob's phone. This sounds great so Bob and Alice get the software and set it up. Each of their phones makes a PKI key pair. The phone has special hardware that keeps the private key very secure so that no one else can get it. They both send their public keys to Charlie who puts them in a big database. This is one of the great ease-of-use features of Charlie's software. Alice and Bob don't have to keep track of all the public keys. They might have hundres of friends they want to exchanges messages with. They don't have to figure out how to get their keys to each other. And Charlie is, after all, honest.

When Alice wants to send a message to Bob, and any of her other friends she composes the message, and sellects the recipients and presses send. The software contacts Charlie's server and askes for Bob's public key, and any others that are needed. The messages is encrypted with each of the public keys and sent trhough Charlie's server to Bob and the others. Bob, and the others, have their own private keys so the message is decrypted and displayed. If Alice signed the message they can request Alice's public key from Charlie's server and verify the signature. All this cryptography happens behind the sceens and is completely invisible to Bob, Alice and their friends. This is the way they like it, because it is easy. And this is great. Or is it? What if Charlie is not honest, or some government has come to Charlie with a warrant for Alice's messages. Charlie might protest saying, warrant or no, I can't give you the messages, they're encrypted and I don't have the keys. The government says that's ok, this is what you do:

Next time Alice asks for Bob's public key Charlie is told to give her a public key called Bob1. Charlie is told to hang on to the private key for Bob1. Alice encrypts the message with the Bob1 key and sends it to Charlie. Charlie can decrypt this message because he has the Bob1 private key. Charlie can read the message, share it with the government and even change it. Charlie then encrypts it with Bob's public key. If Alice signed the original message Charlie then signs it with an Alice1 private key. The message is sent to Bob, who decrypts it with his private key. If he wants to check the signature his software asks for Alice's public key but Charlie's server provides the Alice1 pubic key and the signature is validated. Neither Alice nor Bob are aware anything different has happened.

For me this kind of end-to-end encryption is a little better than mobile-server-server-mobile encryption, but not very much better. There can be no assurance that the end-to-end encryption will continue to be available because one entity, Charlie, controls the communications channel and the distribution of public keys. So how do you fix it.

3) Bob and Alice take a cryptography course and by the end they are very concerned that Charlie may not be handling their keys properly. They don't know that Charlie has done anything to compromise their security, they may even still trust him, but they want better assurance. So they each generate a new PKI key pair, AliceS and BobS. They exchange the keys in a way that doesn't involve Charlie. They meet in person, send them through another trusted person, or some other way they are comfortable with. Not only do they exchange keys, but they take a "finger print" of their keys so they can quickly determine if they have the right one. They can even send their new public keys to Charlie and let him manage them.

Now when Alice wants to send a message to Bob she askes Charlie for Bob's public key. If Charlie sends her anything but the BobS public key, she will see the finger print doesn't match and know somethings wrong. As long as the finger prints does match then they have true end-to-end encryption.

This is a fairly simple description. If you think that option 2 is a great improvement over option 1, then by all means use a system like that. For me the difference isn't worth the trouble of writing the software other than Charlie can stand up and say "end-to-end encryption" and know that the vast majority of users won't know how little protection they are actually getting. Some one who would produce a product like this either doesn't know cryptography very well, or is only doing it for the "security theater" value. Either way, may personal opinion is those people aren't the people I want protecting my data. I would rather trust someone honest enough to say, "we have two options. The first is OK. Probably good enough for the average citizen, but not perfect. And because of that it is free. The second option is really good, but takes some knowledge and extra software to manage effectively. You may want to hire some people to run the software, and we are going to charge extra for it."

Assuming you live in a free country, you can vote with your money and feet for the solution you like. But if you think option 2 is so much better than option 1, why are you using option 1?

You completely "forgot" to comment the hack (full access) of BIS by the five eyes and you ignore the fact that if BBM had implemented a true end-to-end encryption (how it should be), BB wouldn't be able to hand out any data.


What about reading my postings?

I didn't forget to respond to that. It was just a vague reference to intelligence organizations hacking BBM. I've heard that so many times with no substantiation that there really isn't anything for me to say, other than I've heard that, but never seen any credible substantiation. If you want to send along a link to a specific accusation, and it is credible I would be happy to comment, if I can add anything to the material you send. I don't consider any accusations of hacking before BB10 credible, because as you point out the security of BBM over BIS was, at least towards the end, laughable. At the start, when they were sending traffic over Mobitex and GSM it may have had an impact. But then the encryption on those systems is, by todays standards, also laughable.

When it comes to computer security I try to confine myself to documented facts. Which is why I said only that Apple can decrypt iMessages. Not that they are, or will or won't. I don't know if the are, or if they will or if they won't. I don't even know for sure that they know they can. Maybe they think they can't. But they can becuase they manage the public keys, and hide all the details from the users.

[anon(6038817)]

Because sometimes the first patch doesn't actually fix the problem, sometimes the problem isn't fully understood well enough to be properly patched. On the Bash vulnerability, there were several patches, because the conditions to test/check would expand as more testers got involved and found more use cases that were vulnerable. There was 1 bash check, then there was 6 or 7 the following week. Then there were systems that would be patched, say its no longer vulnerable, but were actually vulnerable until the server was rebooted. These are caused by poor testing tools. It takes time to make testing tools that work right.

You can't always rush out a fix. It really depends on the extent of the issue. For example, to fix the Apple goto fail bug, would have been 1 line of change and would restore it back the way it worked for years. When you are fixing something back to how it worked, there is less regression testing needed and low risk complications and that should not have taken 4 months to fix. But when a new bug can change how regular operation works, you need to expand your testing considerably. Or, making sure that that newly discovered type of attack, can't be used in a slightly different way.

You might be able to explain BlackBerry's inaction/ineptitude away if nobody else had released patches. But that is not the reality of the situation.

Apple is the only major tech company that was able to release a working FREAK patch to all of its currently supported products within a week of the announcement. The patch is ready and waiting to be downloaded and installed on millions of Macs, MacBooks, iPads, iPods, and iPhones scattered throughout the world.

BlackBerry has not released a patch yet. And when they do, it will roll out very slowly to its affected products and services.

It really doesn't have to be as complicated as you are trying to make it.

This incident has exposed some glaring chinks in BlackBerry's armor.

[BCITMike]

You might be able to explain BlackBerry's inaction/ineptitude away if nobody else had released patches. But that is not the reality of the situation.

Apple is the only major tech company that was able to release a working FREAK patch to all of its currently supported products within a week of the announcement. The patch is ready and waiting to be downloaded and installed on millions of Macs, MacBooks, iPads, iPods, and iPhones scattered throughout the world.

BlackBerry has not released a patch yet. And when they do, it will roll out very slowly to its affected products and services.

It really doesn't have to be as complicated as you are trying to make it.

This incident has exposed some glaring chinks in BlackBerry's armor.

It really is more complicated than you think it is. Wishing/thinking it isn't, doesn't make it so. All things are not equal. I think I'm just getting tired of the whining about the same things. We get it, its not released fast enough, and that is unacceptable in your books.

[anon(6038817)]

It really is more complicated than you think it is. Wishing/thinking it isn't, doesn't make it so. All things are not equal. I think I'm just getting tired of the whining about the same things. We get it, its not released fast enough, and that is unacceptable in your books.

It's not just the timing. The extent of the vulnerability among BlackBerry's software products is startling. BES and BBM are also vulnerable, for example.

[MADBRADNYC]

It can't be denied.

There is a little bit of Freak in all of us.

Posted via CB10

[thurask]

It's not just the timing. The extent of the vulnerability among BlackBerry's software products is startling. BES and BBM are also vulnerable, for example.

If I remember correctly it's that they all use the same (old) version of OpenSSL. That should change when the fixes roll out.

Posted via CB10

[tipplex]

There is no fix or workaround from BlackBerry yet.

Posted via CB10

[oystersourced]

If I remember correctly it's that they all use the same (old) version of OpenSSL. That should change when the fixes roll out.

Posted via CB10

Which is an issue highlighted a very long time ago.

Posted via CB10

[wutradition]

Posted via CB10

[Deckard79]

Which is an issue highlighted a very long time ago.

Posted via CB10

Indeed it was

Posted via CB10

[wutradition]

Device encryption not affected. Authentication of software I.D. not affected. Transmission of info over secure connections affected. 2/3 of a non-event.

Posted via CB10

[dvarnai]

the vulnerability is FIXED in the latest OS. just tested myself.

[thurask]

the vulnerability is FIXED in the latest OS. just tested myself.

Yep.

Update to 10.3.1.2558 (somehow) to fix FREAK.

Posted via CB10

[wutradition]

Thanks

Posted via CB10

[anon(6038817)]

the vulnerability is FIXED in the latest OS. just tested myself.

Good to know. However, most BB owners will not update with an autoloader or Sachesi. It'll be interesting to see how quickly (or slowly) the carriers push the update.

[oystersourced]

Thank you for confirming the fix.

Posted via CB10

[jdesignz]

Pasaporte Pilipinas | SQW100-1/10.3.1.2558