[plumsauce]

I am seeing that during the imap account setup testing performed by the software that in 10.3.3.3057 it is able to make a SSL connection to the server and the server is reporting:

SSL negotiation successful (TLS 1.0, 1024 bit key exchange, 256 bit encryption)

The two sides have agreed on the connection characteristics.

The phone prompts to accept an untrusted self signed cert. Which it is told to accept by me.

But then the phone drops the socket and reports back on the screen that it could not verify the connection.

The same account/setup on a different Classic running 10.3.2.2639 works fine and has been fine for quite some time.

The same account on the newer OS only works if SSL is disabled. If StartTLS is used, it gets as far as prompting for cert acceptance at the beginning of the StartTLS sequence, then drops again.

This has been tried with SSL levels set at compatible and low.

The one thing that I have forgotten from months ago is whether I needed to import the cert.

But it seems that if it fails even at SSL=low that the newer version of the OS will not downshift successfully to accomodate that setting.

TLS 1.2 is all well and fine, but there are systems that can do no higher than TLS 1.0. The particular server uses RC4 AES256.

Does anyone know of a workaround, or a particular TLS 1.0 cipher suite that passes muster on this version?

If not, I hope the post is at least informative.

[plumsauce]

correction: that should be AES256 SHA-1

[Richard Buckley]

correction: that should be AES256 SHA-1

This is likely your problem. I doubt that you will be able to get a SHA1 cert to work. I tried that, though not very hard, on my server as an experiment while switching to Let's Encrypt certs.

This particular suite indicates some sloppy thinking about security though. AES256 is a great cipher choice, but the reality is that AES128 still provides very good protection. The time to brute force an AES128 key is measured in billions of billions of years. AES256 would take much longer to brute force but uses the same algorithm, so a weakness in one would also weaken the other. In contrast the SHA1 signed keys are very close to being cracked in reasonable time.

Supporting up to date TLS is just a matter of updating the software. If the system can't be updated to support TLS 1.2 the that begs the question of what other unpatched vulnerabilities are inside. One thing that running my own email and web servers has shown is the large number of systems that will probe for weakness and exploit any server they can.

LeapSTR100-2/10.3.3.2205

[rthonpm]

Importing not just the certificate, but the entire certificate chain which has the root signing certificate all the way down to the specific server certificate, would be your best bet.

Is the server one that you're hosting yourself, a corporate server, or a Web based server? If either of the latter two, you'll need to get the certs from their support staff.

Posted via CB10

[Richard Buckley]

Importing not just the certificate, but the entire certificate chain which has the root signing certificate all the way down to the specific server certificate, would be your best bet.

Is the server one that you're hosting yourself, a corporate server, or a Web based server? If either of the latter two, you'll need to get the certs from their support staff.

Posted via CB10

The phone prompts to accept an untrusted self signed cert. Which it is told to accept by me.

Since it is a self signed certificate there is no chain.

I suppose the OP could try importing the certificate as a CA and trusting it.

[plumsauce]

My main problem is that I cannot remember if I imported the cert on the older Classic that does work with the current setup. I was hoping to hear a "doh, you didn't import the cert"

The server is in my fleet. Unfortunately, the current OS only goes up to TLS 1.0 with no upgrade path without a complete revamp. Aside from the cipher limitation the environment is great. The email is mostly incidental use on the receive side. Transmit side goes great guns because there is no dependency on encryption.

Now if someone had a reliable list of cipher combinations that BB10 at 10.3.3.x will attempt to negotiate at each of low, compatible and high encryption settings while in consumer mode (non-BES) that would be useful in seeing if there can ever be a match.

Although, it is true that on the server side it is already logging a successful negotiation at the email server level prior to BB10 throwing up its guts. The message is a bit incomplete as it reports 1024 bit key in 256 bit mode without clearly saying something like AES256-SHA1.

[Richard Buckley]

...
The server is in my fleet. Unfortunately, the current OS only goes up to TLS 1.0 with no upgrade path without a complete revamp. Aside from the cipher limitation the environment is great. The email is mostly incidental use on the receive side. Transmit side goes great guns because there is no dependency on encryption.

...

I would be interested in knowing what threat model you are defending against with that setup. TLS 1.0 has so many known weaknesses I'm willing to bet you aren't actually defended.

One of the reasons Google started rejecting SHA1 certs for web sites, and others followed suit, is because without that push a lot of servers just wouldn't be updated and would result in their users being unprotected without knowing.


LeapSTR100-2/10.3.3.2205

[plumsauce]

The interest in encryption for email back and forth to the server is reasonable protection from casual interception of credentials. The content itself is not earth shattering. No other accessible public services require encryption. Administrative connections are heavily protected.

Since 2000 there has been exactly one hack on one server in the fleet caused by a race condition in how certain defences came up during a reboot.

Google often tries to influence that shape of the internet, and not always to good effect or with disclosure of the true agenda.

[Richard Buckley]

The interest in encryption for email back and forth to the server is reasonable protection from casual interception of credentials. The content itself is not earth shattering. No other accessible public services require encryption. Administrative connections are heavily protected.

Since 2000 there has been exactly one hack on one server in the fleet caused by a race condition in how certain defences came up during a reboot.

Google often tries to influence that shape of the internet, and not always to good effect or with disclosure of the true agenda.

That of course depends on your definitions of reasonable protection and casual interception, but your house your rules.

Playing devil's advocate for a moment -- if I was a user I would point out that were someone able to get my email creds by defeating StartTLS 1.0 you may well be the last to know, or never know. As you point out email content is often not important because it is so poorly protected. But user creds for an email account may be the same creds for more valuable access. Yes, we do tell users not to re-use passwords, but we also tell administrators to run the latest patched code on their servers.

I have never found past experience against malicious actors to be compelling. One reason is that hacks only get better, more available and easier to use over time. So what is considered difficult today can be casually used tomorrow, like FireSheep. Also as the rest of industry moves to better protocols, those left on the old become members of an ever decreasing set of prey for an ever increasing set of predators.

Good luck with your search for a solution. I doubt you will find one since more and more tools are building out not just SHA1 signatures, but TLS 1.0 as well since it has been deprecated by organizations such as NIST and the CPI with EOL set for this summer.

[plumsauce]

Sometimes drastic action needs to be taken. That hacked server? Did the usual forensics on the server to figure out the method used to compromise it, then instructed it to be junked and replaced with a new one.

TLS 1.0 itself may have been deprecated, but in my travels today I read that it is all a matter of selective use. In other words, which subset of cipher suites is permitted in the configuration. Seems reasonable to me.

There are exactly two accounts belonging to human beings on that server. One is a casual user. Both of us use passwords unrelated to anything else.

There is a simple solution in interposing stunnel between users and server. I'm just po'd that I have to jump through hoops when 10.3.2.x just worked.

Now here's a mystery for you.

According to the output from browsing to http://howsmyssl.com the phone offers up cipher suites that overlap with the server's capabilities. According to the server os logs and the email server logs, the two ends are able to negotiate a secured connection.

Then the phone sends an "invalid token" and it's game over.

[anon(5597702)]

Avoid free VPNs.

Posted via CB10

[Richard Buckley]

Sometimes drastic action needs to be taken. That hacked server? Did the usual forensics on the server to figure out the method used to compromise it, then instructed it to be junked and replaced with a new one.

TLS 1.0 itself may have been deprecated, but in my travels today I read that it is all a matter of selective use. In other words, which subset of cipher suites is permitted in the configuration. Seems reasonable to me.

There are exactly two accounts belonging to human beings on that server. One is a casual user. Both of us use passwords unrelated to anything else.

There is a simple solution in interposing stunnel between users and server. I'm just po'd that I have to jump through hoops when 10.3.2.x just worked.

Now here's a mystery for you.

According to the output from browsing to http://howsmyssl.com the phone offers up cipher suites that overlap with the server's capabilities. According to the server os logs and the email server logs, the two ends are able to negotiate a secured connection.

Then the phone sends an "invalid token" and it's game over.

Not really a mystery. Reading the selected answer to this question may help. They are discussing browser use of SSL/TLS and it is 5 years old, but the general principles still apply. Specifically:

...but correct implementations should really check that the TLS connection meets the minimum security requirements after it has been negotiated.

This may point you at a solution. The phone ultimately rejecting the connection might be due to the cryptography negotiated, but it could also be due to the server certificated signature being based on a SHA1 hash. Your solution may be to re-sign using a hash from the SHA2 family.

[plumsauce]

Well the phone is not exactly "rejecting", the server is posting "incorrect token" as the error. At least "incorrect token" is the interpretation of the hexadecimal error number according to posts here and elsewhere, including stack exchange.

As the server is now only offering TLS 1.0, and a limited subset of the more secure algorithms, downshifting is unlikely. After all the negotiation has already succeeded up to the point of the required token.

It is at that point that the phone offers up what is seen as an invalid token.

Therefore, it is likely to be an implementation problem on the phone side which is not solvable at the phone level because there are no knobs to twist other than the previously noted high, compatible, low settings.

The signature on the cert is known to the phone to be SHA1 signed early in the process. If the phone is not happy with that it should not proceed any further. On the other hand, with the signature type known, if it proceeds beyond that, it should proceed on that basis and not change its mind further down the path.