855569 - [Buri][Shira-48042][Email] Message shown when bad certificates are used is not the right one

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P2)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.044
 Firefox os  v1.0.1
 Mozilla build ID: 20130319070203
 
 +++ This bug was initially created as a clone of Bug #429979 +++
 
 DEFECT DESCRIPTION:
 Handset is unwilling to connect to any servers that have unknown server certifcates
 
 REPRODUCING PROCEDURES:
 Email servers are frequently issued with invalid certifcates (e.g. wrong CN, invalid issuer, expired) so operation of email with invalid certifcates is very important.
 But currently when device encounters an unknown server certificate then just stops connecting and gives an error message like unable to connect unknown error. which is not very clear to user why it is not working. User can max think about a wrong userid or password. Where as the root cause is something different. So user will never be able to connectthe server neither will be able to know what is going wrong.
 
 Customer Impact Statement: 
 If the customer attempts to use an email server that has an invalid certifcate it will not work. The user does not get any feedback explaining the reason why, however if they change to plain text the account will verify.
 
 This is also required for us to test the device in our test environment. Because of this issue many of the testing can't be done.
 
 
 EXPECTED BEHAVIOUR:
 Mobile should give suitable prompt.
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:5/5
 
 For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #429979 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
 DEFECT DESCRIPTION:
 
 REPRODUCING PROCEDURES:
 
 EXPECTED BEHAVIOUR:
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:
 
 For FT PR, Please list reference mobile's behavior:

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Certificate errors should be resulting in a 'bad-security' error.  The english string looks like this in email.en-US.properties:

# The error for when we are able to contact a server that should be the mail
# server but we are unable to establish a secure connection.
setup-error-bad-security=Unable to establish a secure connection with "{{server}}". There may be a problem with your network or the server.

If the error is not being properly generated and the string is in the locale in use, then that's a bug in the e-mail app.


For testing purposes, the current options are to:

1) Get a valid certificate.  For example, startcom provides free SSL certificates, although the hostname must be world resolvable:
https://www.startssl.com/?app=1

2) Install the certificate onto the device.  Here's a mailing list post that explains one way of how to do it:
https://groups.google.com/d/msg/mozilla.dev.b2g/B57slgVO3TU/G5TA-PiFI_EJ

In the future the platform might provide a UI in the settings app allowing installation of additional certificates.  There are currently no known plans to allow a user-friendly way of adding a certificate exception because the chances of a man-in-the-middle attack when using (apparently) free wi-fi are very high.

Comment 2

[Daniel Coloma:dcoloma]

Seems like this is a product decision about a new feature. Can ffos product team make the call here?

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

If the product decision is tending towards 'yes' here, any solution will absolutely need to be discussed with the security team and then probably the UX team.  Also note that the actual feature work will likely need to be made in the settings app and require platform exposure of APIs to allow the settings app to add a certificate exception.

Comment 4

[Peter Dolanjski [:pdol]]

Adding Lucas for security input.

Cheng-An, is the error message that Andrew described coming up properly?

(In reply to Andrew Sutherland (:asuth) from comment #3)
> If the product decision is tending towards 'yes' here, any solution will
> absolutely need to be discussed with the security team and then probably the
> UX team. 

Fully agree.

Comment 5

[Cheng-An, XIONG]

(In reply to Peter Dolanjski [:pdol] from comment #4)
> Adding Lucas for security input.
> 
> Cheng-An, is the error message that Andrew described coming up properly?
> 
> (In reply to Andrew Sutherland (:asuth) from comment #3)
> > If the product decision is tending towards 'yes' here, any solution will
> > absolutely need to be discussed with the security team and then probably the
> > UX team. 
> 
> Fully agree.

no error message popup.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Cheng-An, XIONG from comment #5)
> no error message popup.

Ah.  Can you provide the contents of an "adb logcat" from a failed run to help us understand what is actually happening?  Please see https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo for more info on good logcat commands to use to filter down the output, etc.

Comment 7

[Wilfred Mathanaraj [:WDM]]

removing the ffos-product flag

Comment 8

[Daniel Coloma:dcoloma]

Andrew, I am testing this with a device with an old date in order to check what happened in bug 857671. When I am doing that, the secure connection fails (I suspect because the certificate is not valid yet - as I configured my device to be in 1980) and the message displayed is 'Unable to establish a connection with "https://correo.tid.es". There may be a problem with the network'  [unresponsive-server] I suspect in this case the message is at least not accurate. Can you please check if this expected?

Comment 9

[Cheng-An, XIONG]

(In reply to Andrew Sutherland (:asuth) from comment #6)
> (In reply to Cheng-An, XIONG from comment #5)
> > no error message popup.
> 
> Ah.  Can you provide the contents of an "adb logcat" from a failed run to
> help us understand what is actually happening?  Please see
> https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo for more info on good
> logcat commands to use to filter down the output, etc.


Would you check https://bugzilla.mozilla.org/show_bug.cgi?id=847282 and try to get whatever logs you want with the exchange account provided.

Thanks

Comment 10

[Lucas Adamski [:ladamski]]

Adding PaulJT here as he is the security assurance FFOS lead, but not to pass the buck completely: showing a warning would be good but the fundamental behavior of failing on a bad connection is correct.  Providing an override is of dubious value as it usually results in the user making the wrong decision, so I don't think its worth the effort of trying to figure out that UX for 1.1.

Comment 11

[Daniel Coloma:dcoloma]

Andrew, any feedback about comment 8?

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Daniel Coloma:dcoloma from comment #11)
> Andrew, any feedback about comment 8?

We should provide a better error message.  unresponsive-server is not the right error code for us to be providing in this case.  Instead it should be [bad-security]

setup-error-bad-security=Unable to establish a secure connection with "{{server}}". There may be a problem with your network or the server.

Comment 13

[Daniel Coloma:dcoloma]

Morphing it and tef+, Andrew, is that something you can take care of? Thanks!

Comment 14

[Staś Małolepszy :stas]

As Andrew mentioned in comment 1, we already have the 'setup-error-bad-security' string present ad translated.  Will we need to change this string or add new ones?

Comment 15

[Daniel Coloma:dcoloma]

(In reply to Staś Małolepszy :stas (needinfo me, don't just cc) from comment #14)
> As Andrew mentioned in comment 1, we already have the
> 'setup-error-bad-security' string present ad translated.  Will we need to
> change this string or add new ones?

The key point is that 'setup-error-bad-security' is not being displayed in some situations where it should (e.g. my device date is old and that makes the certificate invalid). 

I still think the message could provide more information, but that is not blocker imho.

Comment 16

[Jim Porter (:squib)]

I've been looking at this. Some problems I've encountered:

* XMLHttpRequests don't seem to have any way of detecting that they failed due to bad SSL certs, making it difficult to handle this for ActiveSync.

* The TCP socket used for IMAP returns an nsISSLStatus that seems to let us detect this, but accessing any of its attributes throws the following error: "Error: Permission denied for <app://email.gaiamobile.org> to create wrapper for object of class UnnamedClass"

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jim Porter (:squib) from comment #16)
> * The TCP socket used for IMAP returns an nsISSLStatus that seems to let us
> detect this, but accessing any of its attributes throws the following error:
> "Error: Permission denied for <app://email.gaiamobile.org> to create wrapper
> for object of class UnnamedClass"

Ah, yeah, unit test sees this too when running test_imap_just_auth.js against the 'slocalhost' alias:

ERR: [Exception... "'Error: Permission denied for <testfile://test_imap_just_auth> to create wrapper for object of class UnnamedClass' when calling method: [nsIBadCertListener2::notifyCertProblem]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no] [XPConnect JavaScript]  0

Looking at the commit logs, it would appear like that has probably not worked for an extremely long time.

The only possible fix is for mozTCPSocket to translate the nsISSLStatus result and turn it into a non-sucky error code.

Comment 18

[Johnny Stenback (:jst)]

Andrew, over to you. If you can't get to this by the end of this week, please let me know!

Comment 19

[Jim Porter (:squib)]

Do we want this for ActiveSync as well? That might be more complex (but we could probably fake it by trying a mozTCPSocket when we fail to connect via XHR).

Comment 20

[Chris Lee [:clee]]

What's the latest status here?  Thanks.

Comment 21

[Dylan Oliver [:doliver]]

Status: this one will mostly be solved by bug 861196, with the exception of a small patch for ActiveSync that will follow closely behind.

Comment 22

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/188/files

Pointer to Github pull-request

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

I updated the pull request on friday to cover the ActiveSync case too.

Comment 24

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 742029 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/188/files

r=squib on the PR.

Comment 25

[Andrew Sutherland [:asuth] (he/him)]

landed on gaia-email-libs-and-more/master:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/188
https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/b2d020a93a861a7eb55c69044ab7ddc4ff2d6834

landed on gaia/master:
https://github.com/mozilla-b2g/gaia/pull/9509
https://github.com/mozilla-b2g/gaia/commit/de2a73e76b0bbe05759102d2c370eacb7eece6da

Comment 26

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted de2a73e76b0bbe05759102d2c370eacb7eece6da to:
v1-train: 31c51fdaec762e1e10952f32445fc2b75ee886cb
v1.0.1: f5e4cba0ba61f519b4b0742ff855d45a937cf2c2

Comment 27

[Deepa Subramanian]

Seems issue is partially fixed for B2G18(Leo device)and fully fixed for Inari device with v.1.0.1.
1. Tested on both Wi-Fi on and off for both devices - verified Fixed
2. Tested on Wi-Fi on with wrong domain - Verified Fixed
3. Tested on Wi-Fi on with wrong passwords - Fix matches with master build only for v.1.0.1. Error in Leo does not match with master build.

Please see the attachment for more details. Changing status for v.1.0.1 as verified.

Issue Verified fixed for 
Inari Build ID: 20130506070205
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/ce67220b877d
Gaia: 1e598d8842920d9e0b1743dc6fe9390bd5f6e2df

Issue still remains for 
Leo Build ID: 20130506105248
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/00c554abfc17
Gaia: 94f03a82bc66ad04352d127747ca226368d96363

Also tested against Master build
Unagi Build ID: 20130506031043
Gecko: http://hg.mozilla.org/mozilla-central/rev/b109e2dbf03b
Gaia: 5b50627a6da022258593cecc05dd8e0302f93a6f

Comment 28

[Deepa Subramanian]

Attachment: Screenshot of Leo, Inari and Master

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Deepa Subramanian from comment #27)
> Please see the attachment for more details. Changing status for v.1.0.1 as
> verified.

I think there may be some confusion about the bug and how to verify it.  The problem was that if you tried to set up an account where the IMAP, SMTP server, or ActiveSync (which is just an https server on port 443) had a bad certificate, then we would report an 'unresponsive-server' error instead of 'bad-security'.

As an example of how to determine if a server has a bad certificate, on my Ubuntu 12.10 box with the openssl packages installed I can run the following against my dreamhost-hosted mail account (dreamhost uses their own certificate authority which is not recognized by any vendors):

openssl s_client -CApath /etc/ssl/certs -connect mail.asutherland.org:993 < /dev/null

The last lines of the output look like:
"""
    Verify return code: 21 (unable to verify the first certificate)
---
DONE
"""


If you run the same command against a server with valid certificates, say mail.mozilla.com, the command would be:

openssl s_client -CApath /etc/ssl/certs -connect mail.mozilla.com:993 < /dev/null

and the output would be:
""
    Verify return code: 0 (ok)
---
* OK IMAP4 ready
DONE
"""


Most servers with bad SSL certificates won't be in the ISP database and we don't do domain name guessing right now, so manual setup probably needs to be used against a server for which the certificates are bad per the above method.  If you create a test case for this, asutherland.org is a bad domain to use because I'm going to address the SSL certificate problem soon.

Comment 30

[Andrew Sutherland [:asuth] (he/him)]

Er, but note that the commands I pasted do not enforce the SSL constraint that the hostname the certificate validates for matches the host we are trying to connect to.  So for example, if you were to change mail.mozilla.com to be smtp.mozilla.com, it would still verify okay, but if you pasted the certificate it gave you into an invocation of:

openssl x509 -text

What you would find is that the "X509v3 Subject Alternative Name:" does not include smtp.mozilla.com, just mail.mozilla.com and an internal cluster name.  (That's also a bad domain to use because bug 815771 is supposed to make smtp.mozilla.com go away or otherwise fix it.)