[Hennry Satria]

I updated to 10.3 recently and got this
Attachment 271066
Attachment 271067

Z10STL100-3/10.3.0.296

Can you also test the browser of 10.3 by visiting www.ssllabs.com ? Then please click on "Test your browser" to see the detail on TLS 1.2 support.

I also found that the e-mail client of 10.2.1.2941 does not support TLS 1.1 and TLS 1.2, this e-mail client only support SSL 3.0 and TLS 1.0 which very bad. I checked this capability by setting Gmail account on 10.2.1.2941 and send e-mail, on the Gmail web I open the header and found that 10.2.1.2941 only uses TLS 1.0

I can confirm that Gmail supports TLS 1.2 and always tries to use the highest TLS 1.2 whenever possible; I have tried to simulate this on Thunderbird mail client.

Can you also test the e-mail client of 10.3 with the above method?

Thank you.

[anon(2729369)]

Proof that using older versions of OpenSSL does not offer better protection against attacks.

SSL/TLS MITM vulnerability (CVE-2014-0224)
===========================================

An attacker using a carefully crafted handshake can force the use of weak
keying material in OpenSSL SSL/TLS clients and servers. This can be exploited
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and
modify traffic from the attacked client and server.

The attack can only be performed between a vulnerable client *and*
server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers
are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users
of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

There are other vulnerabilities fixed in OpenSSL 1.0.1h, but most affect DTLS (used in real-time media streaming)

https://www.openssl.org/news/secadv_20140605.txt


Let's see what BlackBerry says about this one

[Richard Buckley]

Proof that using older versions of OpenSSL does not offer better protection against attacks.



There are other vulnerabilities fixed in OpenSSL 1.0.1h, but most affect DTLS (used in real-time media streaming)

https://www.openssl.org/news/secadv_20140605.txt


Let's see what BlackBerry says about this one

Well again it is an OpenSSL vulternability, not an SSL/TLS vulnerability.

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCipherSpec messages, which allows man-in-the-middle attackers to trigger use of a zero-length master key in certain OpenSSL-to-OpenSSL communications, and consequently hijack sessions or obtain sensitive information, via a crafted TLS handshake, aka the "CCS Injection" vulnerability.

[anon(2729369)]

Well again it is an OpenSSL vulternability, not an SSL/TLS vulnerability.

Very true. I've just mentioned it since this thread also covered recent OpenSSL troubles and since it was mentioned at times that it could be safer to be conservative.

[Richard Buckley]

Very true. I've just mentioned it since this thread also covered recent OpenSSL troubles and since it was mentioned at times that it could be safer to be conservative.

And you closed by wondering what BlackBerry's response would be. It is pretty easy to predict that like Heart Bleed BlackBerry handsets won't be affected. BlackBerry products running on affected platforms may be, and will be fixed as patches become available for those platforms.

Edit:

And here is what Dan Kaminsky said about this:

There's no actual attack unless you've got >= 1.01 on both sides of comm. Many bugs aren't vulns.

Posted via CB10

[anon(2729369)]

And you closed by wondering what BlackBerry's response would be. It is pretty easy to predict that like Heart Bleed BlackBerry handsets won't be affected. BlackBerry products running on affected platforms may be, and will be fixed as patches become available for those platforms.

Edit:

And here is what Dan Kaminsky said about this:


Posted via CB10

Handsets are affected since the OS provides a vulnerable version of the library so that apps can be linked to it. I'm hoping most serious developers have updated their app to include a patched version of OpenSSL, but I don't think it's possible to do with the FIPS validated version.

And either Dan Kaminsky or the advisory is wrong. I'm betting on the former.
All it takes is for an attacker to sit between a BlackBerry 10 app and a vulnerable server.

Posted via CB10

[Richard Buckley]

Handsets are affected since the OS provides a vulnerable version of the library so that apps can be linked to it. I'm hoping most serious developers have updated their app to include a patched version of OpenSSL, but I don't think it's possible to do with the FIPS validated version.

And either Dan Kaminsky or the advisory is wrong. I'm betting on the former.
All it takes is for an attacker to sit between a BlackBerry 10 app and a vulnerable server.

Posted via CB10

From your own post:

The attack can only be performed between a vulnerable client *and*
server.

Both client and server have to be using vulnerable versions. It doesn't pay to doubt Dan.

IMO any serious developer wouldn't be using OpenSSL on a platform that had a better SSL/TLS library available. In fact it takes a strong heart for any developer that has looked at OpenSSL source and watched the parade of bugs to use OpenSSL

[anon(2729369)]

The attacker "simply" needs to sit in front of a vulnerable server and he will intercept all communications made from a BlackBerry 10 (or unpatched iOS or Android) device since both the client and the server are vulnerable. Dan was probably talking about one of the other bugs or maybe all OS vendors are simply choosing to ignore this one since they can blame the server admins.

As for OpenSSL, BlackBerry must offer it for a reason. Probably because their library is not API compatible with OpenSSL and most devs porting their apps don't want to have to make too many modifications. Banks, per example, have proven they don't care at all about mobile security (#gotofail). They just use common libraries and rely on the vendor to offer a secure platform.


Posted via CB10

[Richard Buckley]

The attacker "simply" needs to sit in front of a vulnerable server and he will intercept all communications made from a BlackBerry 10 (or unpatched iOS or Android) device since both the client and the server are vulnerable. Dan was probably talking about one of the other bugs or maybe all OS vendors are simply choosing to ignore this one since they can blame the server admins.

Only connections made using a vulnerable version of the OpenSSL library. If you are responsible for, or a user of, applications that use OpenSSL for serious security then it is something to be concerned about. One of the reasons I, and many others, use BlackBerry phones and only use native BB10 programs for sensitive communications is because of the poor security practices use by other developers, including OpenSSL.

As for OpenSSL, BlackBerry must offer it for a reason. Probably because their library is not API compatible with OpenSSL and most devs porting their apps don't want to have to make too many modifications. Banks, per example, have proven they don't care at all about mobile security (#gotofail). They just use common libraries and rely on the vendor to offer a secure platform.


Posted via CB10

Are you suggesting that BlackBerry is responsible for the bugs in OpenSSL because they make it available for developers that want to use it? I'm sure they will make a patched version of OpenSSL available as soon as they can get it approved by the various carriers. That is a pretty sweeping statement about banks, considering how many there are in the world. None of the banks I deal with use OpenSSL on their servers, or their mobile applications. They also, based on their actions, care very much about mobile security.

[anon(2729369)]

Only connections made using a vulnerable version of the OpenSSL library. If you are responsible for, or a user of, applications that use OpenSSL for serious security then it is something to be concerned about. One of the reasons I, and many others, use BlackBerry phones and only use native BB10 programs for sensitive communications is because of the poor security practices use by other developers, including OpenSSL.

I'll say that I'm pretty sure most apps containing sensitive data have upgraded OpenSSL on the backend, because that's the quick fix, but a user doesn't know which version of OpenSSL is running on the server the app he's using connects to. So any app which sync data with the cloud could potentially leak it. Also, there is no way of knowing which library a native app is using. They don't all use the BlackBerry version.

Are you suggesting that BlackBerry is responsible for the bugs in OpenSSL because they make it available for developers that want to use it? I'm sure they will make a patched version of OpenSSL available as soon as they can get it approved by the various carriers.

Yes, just like a car manufacturer is responsible for all the components found in a car. They do recall certain models when something goes wrong.

That is a pretty sweeping statement about banks, considering how many there are in the world. None of the banks I deal with use OpenSSL on their servers, or their mobile applications. They also, based on their actions, care very much about mobile security.

How many banks reported the gotofail bug on iOS? You only see it if you actually check that you're talking to the right server. I'm assuming here that apps on iOS have to use the crypto libraries provided by the OS.

[Richard Buckley]

I'll say that I'm pretty sure most apps containing sensitive data have upgraded OpenSSL on the backend, because that's the quick fix, but a user doesn't know which version of OpenSSL is running on the server the app he's using connects to. So any app which sync data with the cloud could potentially leak it. Also, there is no way of knowing which library a native app is using. They don't all use the BlackBerry version.



Yes, just like a car manufacturer is responsible for all the components found in a car. They do recall certain models when something goes wrong.


How many banks reported the gotofail bug on iOS? You only see it if you actually check that you're talking to the right server. I'm assuming here that apps on iOS have to use the crypto libraries provided by the OS.

So, your are saying that a manufacturer includes a capability for convenience of after market suppliers and customers is responsible for that capability howsoever it is used? You use car manufacturers as an example, so here is a counter example. My car has cargo area tie down attachment points. It also has hardpoints for the attachment of child seat restraints. If I were to install a child seat and attach it to the cargo tie down, or buy a seat from a manufacturer who instructs me to attach it to the cargo tie down, because installing the restraint attachment to the hardpoint is more difficult and time consuming; who is responsible? Should the car manufacturer remove the cargo tie downs? Should they pre-install car seat attachments for one type of seat? What about users who want to use other types of seats?

OpenSSL is what it is. And what it is, and always has been (the current bug was found in code 15 years old) is a mess. I don't know if this batch of fixes is a result of the Linux Foundation reviewing the code base or not. I do expect that once that review hits its stride bug fixes for OpenSSL code will be a routine occurrence. Given the ponderous nature of mobile device updates I do not expect we will see an update for every OpenSSL bug fix.

The reality of this bug is that it requires a MIM between a vulnerable client and a vulnerable server. If the client (on a BlackBerry or other platform) is using a vulnerable version of OpenSSL to communicate with a non-OpenSSL server the connection is not vulnerable. If the same client is communicating with a server running the patched OpenSSL library the connection is not vulnerable. Most affected servers should be patched by now. Of the servers that aren't patched, what other horrors are lurking there?

If you don't know that your client is using high quality crypt, and you don't know that your server is using high quality crypt, and you don't trust everyone in the communications path to not launch a MIM attack against you, then you probably shouldn't be using that product on that communications path. I know this puts the onus on the user, but the majority of users have demanded this situation. Most people want apps and they want them now. It is only when their data leaks they want security, for a few days, then they want their apps.

I have not seen any banks report the iOS goto fail bug, you are right there. None of the banks I deal with said anything about Heart Bleed either. None of them were affected by Heart Bleed because they don't use OpenSSL. To use your car analogy, I don't recall Ford saying that their ignitions switches don't kill people. I do know that goto fail is not the only issue with mobile security. One of the reasons all the banks I deal with recommend using, and provide, native device applications with which they could (and maybe do) provide for all the neglect that happens on mobile platforms. You could take the stance that banks are just hiding the problem. Why you would trust them with your money if you believed that?

[anon(2729369)]

So, your are saying that a manufacturer includes a capability for convenience of after market suppliers and customers is responsible for that capability howsoever it is used? You use car manufacturers as an example, so here is a counter example. My car has cargo area tie down attachment points. It also has hardpoints for the attachment of child seat restraints. If I were to install a child seat and attach it to the cargo tie down, or buy a seat from a manufacturer who instructs me to attach it to the cargo tie down, because installing the restraint attachment to the hardpoint is more difficult and time consuming; who is responsible? Should the car manufacturer remove the cargo tie downs? Should they pre-install car seat attachments for one type of seat? What about users who want to use other types of seats?

OpenSSL is what it is. And what it is, and always has been (the current bug was found in code 15 years old) is a mess. I don't know if this batch of fixes is a result of the Linux Foundation reviewing the code base or not. I do expect that once that review hits its stride bug fixes for OpenSSL code will be a routine occurrence. Given the ponderous nature of mobile device updates I do not expect we will see an update for every OpenSSL bug fix.

The reality of this bug is that it requires a MIM between a vulnerable client and a vulnerable server. If the client (on a BlackBerry or other platform) is using a vulnerable version of OpenSSL to communicate with a non-OpenSSL server the connection is not vulnerable. If the same client is communicating with a server running the patched OpenSSL library the connection is not vulnerable. Most affected servers should be patched by now. Of the servers that aren't patched, what other horrors are lurking there?

If you don't know that your client is using high quality crypt, and you don't know that your server is using high quality crypt, and you don't trust everyone in the communications path to not launch a MIM attack against you, then you probably shouldn't be using that product on that communications path. I know this puts the onus on the user, but the majority of users have demanded this situation. Most people want apps and they want them now. It is only when their data leaks they want security, for a few days, then they want their apps.

I have not seen any banks report the iOS goto fail bug, you are right there. None of the banks I deal with said anything about Heart Bleed either. None of them were affected by Heart Bleed because they don't use OpenSSL. To use your car analogy, I don't recall Ford saying that their ignitions switches don't kill people. I do know that goto fail is not the only issue with mobile security. One of the reasons all the banks I deal with recommend using, and provide, native device applications with which they could (and maybe do) provide for all the neglect that happens on mobile platforms. You could take the stance that banks are just hiding the problem. Why you would trust them with your money if you believed that?

Well, if you include a software component in an OS, especially one designed to keep connections secure, you usually keep it updated. That's what all linux distributions do and I don't see why mobile OSes should be the exception.

Your car example isn't valid (if I understood it properly). Developers are not misusing OpenSSL. They want to establish secure connections and know OpenSSL or have access to examples showing them how to invoke the library. They rely on an OS component to establish a secure connection. That component should be up to date and contain no known vulnerabilities. We can't check every component of everything we use, we have to trust the vendors, auditors, etc.
The least BlackBerry should do is to publish an advisory, letting devs know that that layer is not secure under certain circumstances and that if they control the endpoint, they can easily mitigate the situation, but if they don't, they should update their app to rely on a different library.

And yes, OpenSSL is what it is. You've done your research and know better than using it, when you can, but it's not always possible to avoid it and most devs trust the tools they're given to work with, unless security is their business.
I too think we're only starting to see the results of various audits taking place, but I think it poses an interesting challenge for all mobile OS vendors, but Apple (who can update all their devices whenever they want to).
As an example, BlackBerry has only just published an advisory about a Flash vulnerability which was published by Adobe a year earlier. They wanted to wait for most people to be on 10.2 before announcing it and I think that shows us how slow that OS update process through carriers can be.

About the MIM attack, let's not forget that there can be lots of services/hardware a mobile phone connects to. Not every consumer/SOHO appliances vendor has provided patches, etc. Forget about home routers being updated, etc. Granted, you'll need to use apps to be vulnerable on a BlackBerry, since the BlackBerry browser uses the BlackBerry crypto libs.

I agree with your paragraph on apps. That's exactly the situation I'm talking about and that's the reason I think it's important for companies like BlackBerry to do as much as they can to protect users. Again, an advisory, a note to developers, etc. would let users know what's going on, even if there are still dozens of unplugged holes.

And regarding banks, I probably went too far, since attackers would probably need more than a spoofed website to be able to steal data coming from apps. Surely, most apps do more than just load data from a server after having received a green light from the OS about the validity of the cert... even if I've seen many apps just load the mobile website in a wrapper... But it's a good example of a native crypto library, which is not the messy OpenSSL and which had a massive hole in it. I trust BlackBerry more for not having such big involuntary holes in their library, but they're not infallible.

[Richard Buckley]

Your phrase "BlackBerry should do as much as it can" hits the nail on the head. The developers of OpenSSL left this bug unfixed in their code for 15 years, now somehow BlackBerry need to react orders of magnitude faster?

OpenSSL published an advisory and made a patch available. BlackBerry will, I'm sure make that patch available as quickly as they can. But OpenSSL isn't the OS component that provides security, it is an adjunct. That's why my car analogy is correct. Without an engineering study you can't say that the cargo tie down isn't better than using the hard point, just as without studying the performance of OpenSSL vs BlackBerry Cryptography you can't say which is better. We do have the performance data on the cryptography though.

The people who should be issuing advisories to BlackBerry customers are those application vendors who have used OpenSSL.

Posted via CB10

[anon(2729369)]

Your phrase "BlackBerry should do as much as it can" hits the nail on the head. The developers of OpenSSL left this bug unfixed in their code for 15 years, now somehow BlackBerry need to react orders of magnitude faster?
OpenSSL published an advisory and made a patch available. BlackBerry will, I'm sure make that patch available as quickly as they can.

Yes, that's standard procedure when a vulnerability is discovered. Apple didn't go: "Oh, gotofail has been there for months, there is no rush to fix this". If you decide to audit a component of your server components and discover a serious flaw in a script that you wrote 10 years ago, I'm sure that you're not going to just wait a few more months to fix the problem, just because it's been there for years. You'll just hope that nobody has exploited it and fix it asap.
Of course, as with everything, an assessment has to be made on how critical a problem is. In this case, since it only affects apps which use the OpenSSL library (and not the browser), BlackBerry has decided to ignore the problem, let devs deal with it and implement the patch in their normal release cycle.

But OpenSSL isn't the OS component that provides security, it is an adjunct. That's why my car analogy is correct. Without an engineering study you can't say that the cargo tie down isn't better than using the hard point, just as without studying the performance of OpenSSL vs BlackBerry Cryptography you can't say which is better. We do have the performance data on the cryptography though.

The people who should be issuing advisories to BlackBerry customers are those application vendors who have used OpenSSL.

Wrong, OpenSSL IS one of the OS components which provides security, read the native APIs page. You have 4 options (2 native and 2 OpenSSL based) and BlackBerry presents OpenSSL as a valid and very good option:

Use this full-strength cryptography library to help implement the SSL v2/v3 and TLS v1 protocols in your apps.

Your car analogy does not work... openSSL is the hard points, it's advertised by BlackBerry as a way to implement TLS. The BB lib is the cargo tie downs, a general purpose crypto lib. If the manufacturer discovers a problem with either, it will replace them. If you tie something too heavy or with sharp edges to your tie downs and end up with destroyed seats, then it's your problem because of the way you misused the facilities provided to you. Just like if you don't know what you're doing with a crypto lib and leak data.

And regarding developers, I agree, they should let their users know, but most didn't react when Heartbleed was discovered. I found this page useful to see which service provider is slow to fix their problems:
https://forums.crackberry.com/e?link...token=WO6LfNLe

[Richard Buckley]

Yes, that's standard procedure when a vulnerability is discovered. Apple didn't go: "Oh, gotofail has been there for months, there is no rush to fix this". If you decide to audit a component of your server components and discover a serious flaw in a script that you wrote 10 years ago, I'm sure that you're not going to just wait a few more months to fix the problem, just because it's been there for years. You'll just hope that nobody has exploited it and fix it asap.
Of course, as with everything, an assessment has to be made on how critical a problem is. In this case, since it only affects apps which use the OpenSSL library (and not the browser), BlackBerry has decided to ignore the problem, let devs deal with it and implement the patch in their normal release cycle.

I'm glad you added the second paragraph. Both goto fail and the Heart Bleed bug were introduced by changes in the code. We know the circumstances surrounding the Heart Bleed bug code changes were not conducive to writing bomb proof code. I have not yet seen an explanation from Apple as to how goto fail came to pass. Making changes to code ASAP is one of the biggest causes of bugs. This is why experienced security programmers and companies take time to research security issues, determine the facts and triage their response. I don't understand how you can accept that a bug can languish in a code base for 15 years, but not give a company the time needed to investigate and formulate a response that they can be reasonably sure will fix the known problem while not creating more.

Wrong, OpenSSL IS one of the OS components which provides security, read the native APIs page. You have 4 options (2 native and 2 OpenSSL based) and BlackBerry presents OpenSSL as a valid and very good option:

I am very familiar with the native API documentation. OpenSSL is positioned primarily as a way to bring applications that are currently using OpenSSL to BB10. But they also provide methods for using the OpenSSL API but replacing the OpenSSL cryptography engine with the BlackBerry FIPS approved cryptography:

You can use FIPS-validated cryptography in your OpenSSL application by calling ENGINE_load_sb(). This function uses the OpenSSL dynamic ENGINE to load and register the Security Builder Engine for OpenSSL. This replaces the default cryptography used by OpenSSL with the BlackBerry OS Cryptographic Engine (version 5.6), which has been validated to FIPS 140-2, Level 1, under certificate #1578.

How this interacts with the bugs in the OpenSSL implementation I, of course, do not know. It may take some time for BlackBerry to determine exactly to what extent, if any, the bug affects software using this feature. I don't know what more BlackBerry can do to help developers provide good secure cryptography.

Your car analogy does not work... openSSL is the hard points, it's advertised by BlackBerry as a way to implement TLS. The BB lib is the cargo tie downs, a general purpose crypto lib. If the manufacturer discovers a problem with either, it will replace them. If you tie something too heavy or with sharp edges to your tie downs and end up with destroyed seats, then it's your problem because of the way you misused the facilities provided to you. Just like if you don't know what you're doing with a crypto lib and leak data.

Unless the hard point is simply an alternate interface to the tie down. And I was just in a automotive service department. At least one manufacturer will not take any responsibility for tires. I don't know if this is a result of Ford's problems with tires on the Explorer. But, this manufacturer refers any issues with tires to the tire manufacturer.

And regarding developers, I agree, they should let their users know, but most didn't react when Heartbleed was discovered. I found this page useful to see which service provider is slow to fix their problems:
https://forums.crackberry.com/e?link...token=s4i16Df2

There is an old saying from my military service days: "Lack of proper planning (or in this case, proper response) on your part does not constitute an emergency on my part." I'm sure when BBSIRT has analyzed and understands the impact on their products they will issue a statement and options for remediation. And you are right with your Adobe example, it can take a long time to to it right. It took OpenSSL 15 years to get it right. By that metric BlackBerry has until 2029. I'm sure we will hear something before then.

[thurask]

Good news (ish):

http://btsc.webapps.blackberry.com/b...ListHelperImpl

With 3175/3247, apparently a device on a BES can use TLS 1.1/1.2 now. Evidently, we need to wait for 10.3 in order to get it for devices without a BES.

[Superdupont 2_0]

So, this thread inspired me to browse some https websites with Firefox and check the TLS encryption (just click the lock symbol in the URL bar and then click �more information�).

Observations were very mixed, I would like to share only two:

https://blackberryid.blackberry.com/bbid/login/

is using poor TLS_RSA_WITH_RC4_128_SHA ...booh!

https://passport.mobilenations.com

is using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 �wow!



As a next step, I changed the default settings of Firefox.

about:config > search �SSL3� to find the ciphers> leave only ciphers with dhe or ecdhe �true� and set all others to �false�.

Now browse to https://blackberryid.blackberry.com/bbid/login/ again and voil�

This time the result is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA


I think this is a typical problem in the internet:
A webserver/mailserver has strong cipher suites, but offers a weak cipher to the client/mailserver as �preferred�. Both sides are just happy with any first match and as result you get weak encryption.

There are some nice explanations here


BTW, unfortunately some https sites are no longer working with these strict settings in Firefox!


Next I wondered what Internet Explorer and Outlook are doing, because here we have the same problem.

To make it short, one can very easily disable/enable cipher suites and change the order of preference.

Just run gpedit.msc. as administrator and follow only the first five points of this manual

... if you ask me which (order of) cipher suites I recommend for Windows, I would say it depends on the websites and mailservers you are using.
However, just for some orientation, one can go to this website
and scroll down to �What is the default cipher suite order?�� okay, for starters I would follow their recommendation.

If you can't receive any e-mails or can't access certain websites after the change, you can go back to the default settings or change the provider.

[anon(2729369)]

Yep, it's a problem when server/services advertise ciphers in the wrong order.
The BetterCrypto project has a good PDF on how to configure things right. I find their Cipher String A to be too incompatible and String B to be too permissive, but they're a good starting point and they give advice on picking the ones that should work for different use cases
Applied Crypto Hardening PDF

[Hennry Satria]

In Thunderbird mail client, we can set this mail client to use the highest encryption for connection to the mail server.

Unfortunately, this kind of capability is not available to any smartphone mail client (including iOS, Windows Phone, Android and BB10).

Any advise for this?

[Richard Buckley]

In Thunderbird mail client, we can set this mail client to use the highest encryption for connection to the mail server.

Unfortunately, this kind of capability is not available to any smartphone mail client (including iOS, Windows Phone, Android and BB10).

Any advise for this?

I'm not sure what you are talking about here. I use SSL/TLS connections from my BlackBerry to all my mail servers.

Posted via CB10

[Hennry Satria]

I'm not sure what you are talking about here. I use SSL/TLS connections from my BlackBerry to all my mail servers.

Posted via CB10

From my understanding, if we are talking SSL/TLS connection on between mail client and mail server, then the steps would be as follow:

1. The mail client contacts mail server
2. The mail client and mail server would negotiate the encryption, SSL 3.0 or TLS 1.0 or TLS 1.1 or TLS 1.2
3. To allow compatibility with most mail server (including the old one), Thunderbird allows SSL 3.0 (which actually proven not secure).
4. During the negotiation, usually the lowest encryption is chosen for compatibility.
5. In Thunderbird, we can set that the client would negotiate to use TLS 1.2 only.

In blackberry, if you look the mail header, it usually choose SSL 3.0 while connecting to Gmail, although Gmail supports TLS 1.2. If there is a way to set the BB mail client to use TLS 1.2 only then the connection would be more secure.

CMIIW

[Richard Buckley]

I always find it interesting that people seem to focus on version numbers rather than implementation. For example the TLS 1.1 and 1.2 implications in OpenSSL came with the first release of the Heart Bleed bug. Those services that delayed installing those versions were not vulnerable.

It is good to stay up to date with fixes to existing code as bugs are found. But, especially with cryptography, if you want to be secure you often don't want to be at the bleeding edge. It is wise to hang back and let the adventurous find the problems.

Google specifically is running their own unique version of SSL/TLS, based on OpenSSL and with their own modifications layered on top. They were vulnerable to Heart Bleed, and potentially problems introduced by their own code.

Posted via CB10

[Superdupont 2_0]

If you do the webserver-test on ssllabs.com with gmail.com, then you see some handshake simulations below the cipher suites.

According to these handshake simulations only IE6 on Win XP would use SSL3.
It's very hard for me to believe that any BlackBerry OS is using less than TLS1.0 when connecting to gmail.

However, I totally agree that modifying the cipher suites in BB 10 would be a very, very nice feature for users (not only BES admins).

[Richard Buckley]

However, I totally agree that modifying the cipher suites in BB 10 would be a very, very nice feature for users (not only BES admins).

That would be nice, but the tech support person in me cringes at the thought of people who wouldn't know what they're doing setting themselves up to not be able to connect to half the servers on the net.

It's going to be bad enough when Chrome starts dissing SHA1 signed certs that expire after December 2015.

Posted via CB10

[anon9111501]

You are really right, ofutur ! Thank you !

And one more time we have to wait that TLS 1.2 is integrated
and all unsecure/dated protocols would be removed. ( Or left at the end of the row )
I really hope BlackBerry would do this IN TIME, NOW ! With the next Official OS Update or whatever.

I was wondering about that old TLS a long time, but many BlackBerry "Lovers" here are very disappointed if one awakes them of their "Super transparent HiSec Dream".