Closed Bug 1009233 Opened 5 years ago Closed 5 years ago

Help on mail account settings for authentication method needs updating

Categories

(SeaMonkey :: Help Documentation, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.30

People

(Reporter: iann_bugzilla, Assigned: rsx11m.pub)

Details

Attachments

(1 file, 6 obsolete files)

Currently the help talks about "Use secure authentication" whereas the account settings now has a drop down "Authentication method". The help needs updating to reflect the changes made in bug 525238
I'll have a look (counting three occurrences of that label in mailnews_account_settings.xhtml).
Assignee: nobody → rsx11m.pub
Attached patch Proposed patch (obsolete) — Splinter Review
This patch adds CRAM-MD5, GSSAPI, Kerberos, and NTLM to the Glossary and updates the descriptions of the IMAP, POP, and SMTP server settings. Only minor changes were done for NNTP as most options aren't available for news servers.

BenB, if you have time, can you have a look at this if the descriptions are reasonably correct from the technical perspective? I've never worked with NTLM, so this part is somewhat guesswork. Thanks.
Attachment #8424475 - Flags: review?(iann_bugzilla)
Attachment #8424475 - Flags: feedback?(ben.bucksch)
Status: NEW → ASSIGNED
Comment on attachment 8424475 [details] [diff] [review]
Proposed patch

For a help text, CRAM and Kerberos has too much tech talk and is too abstract. It is correct, but won't help your mom to understand. NTLM descr was better.

IIRC, we're asking for a password for NTLM, so it's not really SSO. (Don't ask me how it functions.)

I propose:
CRAM-MD5   A mechanism to cryptocraphically encrypt the password before it's sent to the server, so that nobody listening to the internet connection can see the actual password.
GSSAPI   Successor to Kerberos. A way to use single-signon, smartcards or other custom methods to authenticate access without using passwords for each service. Used mostly in large enterprise/institutional networks where authentication is provided by centralized services like LDAP.
NTLM   An authentication protocol in local networks that is proprietary to Microsoft Windows. Used mostly in enterprise/institutional networks.
Attachment #8424475 - Flags: feedback?(ben.bucksch) → feedback-
(In reply to Ben Bucksch (:BenB) from comment #3)
> For a help text, CRAM and Kerberos has too much tech talk and is too
> abstract. It is correct, but won't help your mom to understand. NTLM descr
> was better.

Ok, too much engineering level even for the glossary. I'll have another look at the Kerberos description and simplify it.

> IIRC, we're asking for a password for NTLM, so it's not really SSO. (Don't
> ask me how it functions.)

Ok, that's what I wasn't quite sure about, so it's not like Kerberos. Microsoft themselves recommends replacing NTLM with Kerberos, hence I thought that it was kind-of equivalent in functionality.

> GSSAPI   Successor to Kerberos. 

Hmm, successor? It was my understanding that GSSAPI is essentially the standard specification and Kerberos an implementation that can be used with that API; http://tools.ietf.org/html/rfc1964 says:

   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using Kerberos Version 5 technology (as specified in RFC 1510).

So this looks more like GSSAPI is wrapping around Kerberos 5 to provide the standardized API...
Sounds like that, "underlying mechanism" = Kerberos? http://tools.ietf.org/html/rfc2078

   The Generic Security Service Application Program Interface (GSS-API),
   as defined in RFC-1508, provides security services to callers in a
   generic fashion, supportable with a range of underlying mechanisms
   and technologies and hence allowing source-level portability of
   applications to different environments. This specification defines
   GSS-API services and primitives at a level independent of underlying
   mechanism and programming language environment, ...

Section 5 of this RFC lists Kerberos in the context of "Mechanism-Specific Example Scenarios" which would support how I'm reading this.

Thus, your GSSAPI description would probably replace nicely my current Kerberos glossary item, and I'll have another look how to de-techify the GSSAPI paragraph.
I think the best way to eliminate the need of explaining the subtle interrelationship between GSSAPI and Kerberos is to simple combine those two items in a single "Kerberos / GSSAPI" glossary point along the lines is comment #3. There is always Wikipedia if someone wants to look into the details.
Attached patch Proposed patch (v2) (obsolete) — Splinter Review
This version includes changes to glossary.xhtml for the previous couple of comments.

I've kept GSSAPI item to retain the full wording of the acronym (it's nowhere linked from unless you search for it directly) and it now just point to the related Kerberos entry. A couple of changes from comment #3 to keep some points that I wanted to make and to utilize some of the phrases defined elsewhere in the glossary.

Additional changes: I've added TLS to "secure connection" (which currently only mentions the old SSL) and corrected a grammatical typo in the XUL description.
Attachment #8424475 - Attachment is obsolete: true
Attachment #8424475 - Flags: review?(iann_bugzilla)
Attachment #8425102 - Flags: review?(iann_bugzilla)
GSSAPI vs. Kerberos: GSSAPI is basically the new API to Kerberos. It was abstracted to allow other implementations, but there aren't many other, as far as I know, just one other MS implementation. Most of the time when people use GSSAPI, they actually want to use Kerberos. Plus, nobody knows what GSSAPI is (including myself, until I had to implement it), but many UNIX techies know Kerberos. This is why our UI says "GSSAPI / Kerberos", because technically it's GSSAPI, but actually, it's basically just Kerberos.
certificate-based authentication = Verification of identity based on certificates
My German teacher tought me to *never* use the to-be-defined work in the definition. You'll need to explain what a certificate is. Is it something like a law degree? :-)

+ <dt id="secure_authentication">secure authentication</dt><dd>A type of
+  authentication which can be achieved by using
+  a clear-text password over a secure
+  connection (thus the communication between client and server is
+  encrypted), by separate encryption of the password (e.g.,
+  using CRAM-MD5, or by mechanisms like
+  Kerberos and NTLM

Secure authentication:
Clear-text passwords - even when sent over SSL - are not considered "secure authentication". It is any one of: CRAM-MD5, GSSAPI/Kerberos, NTLM.
This is a deprecated legacy setting and used only when migrating old profiles. You cannot select it in the UI for new accounts, and even for old accounts, it should be changed to a more concrete setting.
secure connection
A server conneciton using SSL or TLS. All data between your computer and the email server is encrypted, so that no intermediary listening to your internet connection can read it. The data itself is not encrypted and it can be read in the clear by the server.
To ensure that you are talking to the right server and not an intermediate, the server needs to identify itself using a "certificate" which states that the server belongs to the right party and which is signed by a trusted third party called "certificate authority". Therefore, it is important to heed certificate warnings.
FWIW, we don't mention CRAM-MD5 in the UI text, because a) it's too obscure to understand and b) there may be DIGEST-MD5 (although that's rarely used). This is auto-negotiated. In the UI, it's called "encrypted password", and I suggest to call the glossary entry like that, refer "CRAM-MD5" there.
Thanks, that's a lot of stuff!

(In reply to Ben Bucksch (:BenB) from comment #8)
> GSSAPI vs. Kerberos: GSSAPI is basically the new API to Kerberos. ...
> but many UNIX techies know Kerberos. This is why our UI says "GSSAPI / Kerberos",
> because technically it's GSSAPI, but actually, it's basically just Kerberos.

Ok, so I think that leaving Kerberos as the main entry and just letting GSSAPI refer to it should hit the right level.

(In reply to Ben Bucksch (:BenB) from comment #9)
> My German teacher tought me to *never* use the to-be-defined work in the
> definition. You'll need to explain what a certificate is. Is it something
> like a law degree? :-)

That's why I've added the link to "certificate" because otherwise the old text is completely circular. Should be sufficient in this way, any expansion would I think replicate what's explained elsewhere.

> +  a clear-text password over a secure
> +  connection
> Clear-text passwords - even when sent over SSL - are not considered "secure
> authentication". It is any one of: CRAM-MD5, GSSAPI/Kerberos, NTLM.

Ok, I was wondering myself about this, but given that it was mentioned in the old text I've left it there. I will remove or rephrase that reference given that it may be confusing (though from the user's point of view, the main thing is that the credentials are securely submitted).

> This is a deprecated legacy setting and used only when migrating old
> profiles. You cannot select it in the UI for new accounts, and even for old
> accounts, it should be changed to a more concrete setting.

Are you thinking of the obsolete "STARTTLS, if available" for which this applies? You can choose connection security of "None" with "Normal password" turning to "Password, transmitted insecurely" - thus, you are permitted to select an unsafe combination, which is why I've expanded on the warnings which combinations are safe and which ones are not in the main help update for the settings.

(In reply to Ben Bucksch (:BenB) from comment #10)
> secure connection
> A server conneciton using SSL or TLS. All data between your computer and the
> email server is encrypted, so that no intermediary listening to your
> internet connection can read it. The data itself is not encrypted and it can
> be read in the clear by the server.

Probably more like "may not be encrypted" given that you can combine secure connection with secure authentication (or, in general terms, send encrypted content over an encrypted line).

> To ensure that you are talking to the right server and not an intermediate,
> the server needs to identify itself using a "certificate" which states that
> the server belongs to the right party and which is signed by a trusted third
> party called "certificate authority". Therefore, it is important to heed
> certificate warnings.

I don't think that we need to refer to "certificate authority" again, this process is described in more detail in the "certificate" entry. The user-facing warnings are certainly an important addition.

(In reply to Ben Bucksch (:BenB) from comment #11)
> This is auto-negotiated. In the UI, it's called "encrypted password", and I
> suggest to call the glossary entry like that, refer "CRAM-MD5" there.

Right, CRAM-MD5 is one of the cryptographic algorithms to encrypt passwords. I'll add the latter and make it the main entry, but will keep CRAM-MD5 as a separate entry (consistent with secure connection and mentioning SSL/TLS separately).
Attached patch Proposed patch (v3) (obsolete) — Splinter Review
Next iteration per comment #12. Note that the help for the main settings still explicitly refers to "like CRAM-MD5" with link to the glossary, given that linking an "encrypted password" when explaining "Encrypted Password" as the option would be a little weird. I've left a link from "secure authentication" to "secure connection" for the sake of disambiguation ("not to be confused with").
Attachment #8425102 - Attachment is obsolete: true
Attachment #8425102 - Flags: review?(iann_bugzilla)
Attachment #8425541 - Flags: review?(iann_bugzilla)
>> "secure authentication". It is any one of: CRAM-MD5, GSSAPI/Kerberos, NTLM.
>> This is a deprecated legacy setting and used only when migrating old profiles.

> Are you thinking of the obsolete "STARTTLS, if available" for which this applies?

No, "secure authentication" is an actual setting value for auth.
In old versions, it used to be the only setting for auth, a boolean. Now it's one of the (enum) values.
See bug 525238.
and MailNewsTypes2.idl http://mxr.mozilla.org/comm-central/source/mailnews/base/public/MailNewsTypes2.idl#81
Set your auth pref to int 8 to see it in the UI.

> > The data itself is not encrypted and it can be read in the clear by the server.
> Probably more like "may not be encrypted"

Well, this is talking about SSL, and SSL doesn't encrypt the data. Suggestion:
"The data itself is not encrypted by SSL and it can be read in the clear by the server."
(In reply to Ben Bucksch (:BenB) from comment #14)
> No, "secure authentication" is an actual setting value for auth.
> Set your auth pref to int 8 to see it in the UI.

Eh, ok. Given that chances are slim that this will ever show up (are they?), I'd like to avoid adding this setting to the documentation in order not to confuse people. Note that we don't have the obsolete option "STARTTLS, if available" documented either, even though someone could still have it in some migrated profile (and I have removed it from the SMTP settings help for consistency with IMAP/POP).

> Well, this is talking about SSL, and SSL doesn't encrypt the data.

Yes, but you can send already encrypted data over SSL, so the data itself may or may not be encrypted but is secured either way (which was the point to be made).  ;-)

> "The data itself is not encrypted by SSL and it can be read in the clear by the server."

I don't see what's wrong with the current text "The data transmitted may not be encrypted itself but is secured in this way." This should be a simple statement and in line with the message I want to convey.
> > "secure authentication"

> I'd like to avoid adding this setting to the documentation in order not to confuse people.

Agreed.

> the data itself may or may not be encrypted but is secured either way

I don't consider data transmitted over SSL to be "secure". If I send an email to you, and Google sees it, and 35 secret services in between see it, the email wasn't "secure" in my book. That's not even starting with lack of viruses or phishing, which for me should be included in "secure", which is why I think this term has no business anywhere near SSL.
(You can disregard my last comment, given that this is just a help text entry. Nobody will read it anyway, so no need to fuss about it. :) )
If you have a different term than "secured" I'll be happy to change that; "protected" may not fully address your concern about SSL/TLS vulnerabilities either.
"encrypted". Comment 10, adapted after your comments:

secure connection
A server conneciton using SSL or TLS. All data between your computer and the email server is encrypted, so that no intermediary listening to your internet connection can read it. The data can still be read by the email server.
Thus, the server needs to identify itself using a "certificate". A bad certificate can hint at an attacker, so it is important to heed certificate warnings.

(Please note that "secure connection" was a term from the old UI. We no longer have this exact term, it's called "Connection security: SSL" in prefs now.)
Thanks but I still don't quite like it. ;-)

(In reply to Ben Bucksch (:BenB) from comment #19)
> "encrypted".

Hmm, "The data transmitted may not be encrypted itself but is encrypted in this way" would be rather circular again, so that wouldn't make much sense. I'd have to change "in this way" by something more specific then, like "during the transport" which is sort-of what I described just before that.

Back to the original term in the current patch, I'm also talking about "secured" for the password when discussing encrypted passwords, so that would be consistent even if the level of security may differ or be on a different level here (as you pointed out initially, this is a help text and thus we can afford to be a bit fuzzy for the sake of making it clear to understand for the non-techy user).

> The data can still be read by the email server.

I don't understand why this sentence seems to be so important. Even if the data itself is encrypted it can still be read by the server as long as the server knows how to decrypt it. Conversely, the server needs to decrypt the SSL/TLS transport stream in order to be able to read the data contained in it, thus an action is necessary by the server either way. The only distinction is whether the data itself or the transport is encrypted, writing it in the way you suggest seems to be rather confusing.

> (Please note that "secure connection" was a term from the old UI. We no longer
> have this exact term, it's called "Connection security: SSL" in prefs now.)

I'd consider "secure connection" as universal, not just for the mail/news settings (also applied to HTTPS connections for the browser, etc.). We don't have "secure authentication" either in the UI any more, yet it's a generic description for the various methods to achieve that.

> Thus, the server needs to identify itself using a "certificate". A bad certificate
> can hint at an attacker, so it is important to heed certificate warnings.

This should be a more compact representation of what I currently have used from your previous text,

>+  that you are talking to the right server and not an intermediate, the server
>+  needs to identify itself using a <a href="#certificate">certificate</a> which
>+  is used to verify the server&apos;s identity.  Therefore, it is important to
>+  heed any certificate warnings as they may indicate a compromised server or
>+  an attack on the connection.</dd>

though I'm distinguishing here between a compromised (or fake) server and connection attacks (MITM), which may not be relevant given that an attack is an attack regardless of what or how it attacks.
Attached patch Proposed patch (v4) (obsolete) — Splinter Review
Modified version including the last part of comment #19 with some changes.
No modifications to anything other than the "secure connection" description.

 - I went with "protected" instead of "secured" now which sounds less absolute.

 - I use "eavesdropping" rather than "listening" as we have a glossary point
   for it (I'm just not linkifying it to avoid too much blue in the text, and
   it's right above "encrypted" which is linked to).

 - I made it "attack on the server or the connection" to keep both covered.

 - I'm not sure about "no intermediary eavesdropping" given that an attacker
   doesn't necessarily have to be in the communication as "intermediary" but
   just has to be in the same network (e.g., a public WiFi hotspot). On the
   other hand, "intermediary" makes it clear that the attacker somehow has to
   be part of the network chain and can't be completely aside.
Attachment #8425541 - Attachment is obsolete: true
Attachment #8425541 - Flags: review?(iann_bugzilla)
Attachment #8427770 - Flags: review?(iann_bugzilla)
> We don't have "secure authentication" either in the UI any more

We do, for some users, see comment 14.

> > The data can still be read by the email server.
> I don't understand why this sentence seems to be so important.

Because I don't trust email providers. Google reads all mail and reserves the right to use the information for any means. Ditto governments. SSL doesn't mean "secure" for me by any means.

Many users are not aware of this. In part, that's because of fuzzy wording in software that said "This site is secure". That's nonsense.

> Even if the data itself is encrypted it can still be read by the server

PGP can do it, SSL can't.

> I still don't quite like it. ;-)

Do as you like, then :)
(In reply to Ben Bucksch (:BenB) from comment #22)
> > We don't have "secure authentication" either in the UI any more
> We do, for some users, see comment 14.

Err, yes - but only for a deprecated setting. Thus, any "normal" user shouldn't see it, hence it's not visible for the sake of the Help content.

> Because I don't trust email providers. Google reads all mail and reserves
> the right to use the information for any means. Ditto governments. SSL
> doesn't mean "secure" for me by any means.

Ok, point taken. I don't know if you had a look yet on the new patch, but I've rephrased it a little:

> The data itself may not be encrypted but is protected during transmission.

to make the distinction clearer that it only applies to the communication.

> Do as you like, then :)

As said, I'll leave it to IanN to make the final call, but what I have now is hopefully a good compromise to reasonably cover all points.
Attached patch Proposed patch (v5) (obsolete) — Splinter Review
Apologies for the inflation of incremental patches, but on a third thought...

(In reply to rsx11m from comment #23)
> > The data itself may not be encrypted but is protected during transmission.

I've added "to and from the server" to make it unambiguous that the encryption ends at the connection with the server and isn't going all the way thru the recipient (for e-mails).

(In reply to rsx11m from comment #21)
>  - I'm not sure about "no intermediary eavesdropping" given that an attacker
>    doesn't necessarily have to be in the communication as "intermediary" but
>    just has to be in the same network (e.g., a public WiFi hotspot).

I've change "intermediary" to "third party" which is a bit more neutral to the location. The term "eavesdropping" itself should convey that you need to be physically close to the line.
Attachment #8427770 - Attachment is obsolete: true
Attachment #8427770 - Flags: review?(iann_bugzilla)
Attachment #8427951 - Flags: review?(iann_bugzilla)
Comment on attachment 8427951 [details] [diff] [review]
Proposed patch (v5)

>+++ b/suite/locales/en-US/chrome/common/help/glossary.xhtml

>+<dt id="encrypted_password">encrypted password</dt><dd>Used for
>+  <a href="#password-based_authentication">password-based authentication</a>
>+  to achieve <a href="#secure_authentication">secure authentication</a>.
>+  The user&apos;s password is encrypted before it is sent to the server
>+  (e.g., by methods like <a href="#cram_md5">CRAM-MD5</a>) to prevent that
>+  anyone eavesdropping on the connection can see it in clear text.  This
This is a bit awkward perhaps:
...to prevent anyone that is eavesdropping on the connection from seeing it in clear text.

>+<dt id="secure_connection">secure connection</dt><dd>A connection using
>+  <a href="#ssl">SSL</a> or <a href="#tls">TLS</a>.  All communication between
>+  your computer and the server is <a href="#encryption">encrypted</a> so that
>+  no third party eavesdropping on your connection can read it.  The data
>+  itself may not be encrypted but is protected during transmission to and
This is confusing, first of all it is encrypted then it may not be? Are you saying that data between your computer and the server is encrypted but after that it might not be? (i.e. between the server and another server).

>+  from the server.  To proof its authenticity to the client, the server needs
>+  to identify itself using a <a href="#certificate">certificate</a>.  A bad
>+  certificate can indicate an attack on the server or the connection, thus it
>+  is important to heed certificate warnings.</dd>
Is "bad" the best word here, would invalid or incorrect be better?

>+++ b/suite/locales/en-US/chrome/common/help/mailnews_account_settings.xhtml
>@@ -205,30 +205,61 @@
>   <li><strong>Port</strong>: Unless otherwise instructed to do so by your
>     service provider or system administrator, leave this setting
>     unchanged.</li>
>   <li><strong>Connection security</strong>: Choose one of the available options
>     to establish a <a href="glossary.xhtml#secure_connection">secure
>     connection</a> to your incoming IMAP server. You can choose one of these:
>     <ul>
>       <li><strong>None</strong>: &brandShortName; will use a plain connection,
>+        without encryption at all. You should choose this <em>only</em> if your
>+        incoming server allows for password encryption or doesn&apos;t support
I don't think "for" is required here.

>+        any type of security.</li>

>+  <li><strong>Authentication method</strong>: Choose one of the available
>+    options to use <a href="glossary.xhtml#secure_authentication">secure
>+    authentication</a> with your incoming IMAP server. You can choose one of
>+    these:
>+    <ul>
>+      <li><strong>Normal password</strong>: &brandShortName; will send your
>+        password as clear text, without encryption at all. This option is
>+        safe when SSL/TLS or STARTTLS is used.</li>
>+      <li><strong>Password, transmitted insecurely</strong>: Same as
>+        <q>Normal password</q> but used with a connection security of
>+        <q>None</q> and hence unsafe. Do <em>not</em> choose this unless your
Perhaps should say "...but only available when a connection security of <q>None</q> is selected and hence is unsafe."

>+        incoming server doesn&apos;t support any type of security at all.</li>
>+      <li><strong>Encrypted password</strong>: Require an encryption of the
Maybe "the" instead of "an"?
>+        user&apos;s credentials as supported by the server, such as
>+        <a href="glossary.xhtml#cram_md5">CRAM-MD5</a>. This option is safe
>+        to use even if the connection security setting is <q>None</q>, but
>+        only the password would be secured in this way, not any content.</li>
>+      <li><strong>Kerberos / GSSAPI</strong>: Choose this option if your
>+        computer is set up for a secure authentication using
I don't think "a" is required here.
>+        <a href="glossary.xhtml#kerberos">Kerberos</a>. You may need to
>+        acquire a Kerberos ticket by a separate program, or it may be
Perhaps "...ticket by using a separate program."
>+        assigned to you when logging into your computer.</li>
>+      <li><strong>NTLM</strong>: Choose this option if your computer is set up
>+        for a secure authentication using an <a href="glossary.xhtml#ntlm">NT
I don't think "a" is required here.
>+        LAN Manager</a>. In general, Kerberos is preferred over NTLM as it
Maybe "should be" rather than "is"
>+        provides for a higher level of security.</li>
>+      <li><strong>TLS Certificate</strong>: Choose this option to use
>+        <a href="glossary.xhtml#certificate-based_authentication">certificate-based
>+        authentication</a> on a connection with SSL/TLS or STARTTLS enabled,
>+        without providing any password for authentication.</li>
Maybe "without the need to provide" instead of "without providing"

Same comments above, where applicable, for the POP and SMTP sections too.

f+ for the moment as I would like to review the new patch.
Attachment #8427951 - Flags: review?(iann_bugzilla) → feedback+
(In reply to Ian Neal from comment #25)
> >+<dt id="secure_connection">secure connection</dt><dd>A connection using
> >+  <a href="#ssl">SSL</a> or <a href="#tls">TLS</a>.  All communication between
> >+  your computer and the server is <a href="#encryption">encrypted</a> so that
> >+  no third party eavesdropping on your connection can read it.  The data
> >+  itself may not be encrypted but is protected during transmission to and
> This is confusing, first of all it is encrypted then it may not be? Are you
> saying that data between your computer and the server is encrypted but after
> that it might not be? (i.e. between the server and another server).

InvisibleSmiley wanted the distinction between just encrypting the connection and actually encrypting the data, only the latter providing "real" security (see comment #10, comment #14 and following).

> >+  from the server.  To proof its authenticity to the client, the server needs
> >+  to identify itself using a <a href="#certificate">certificate</a>.  A bad
> >+  certificate can indicate an attack on the server or the connection, thus it
> >+  is important to heed certificate warnings.</dd>
> Is "bad" the best word here, would invalid or incorrect be better?

It can be invalid, not being vouched for by a CA, revoked, simply expired, or forged by a hacker, thus neither just "invalid" nor "incorrect" match the full range of possible "bad" certificates.
(In reply to rsx11m from comment #26)
> InvisibleSmiley wanted the distinction ...

Huh, my apologies - that was BenB of course.  :-(
(In reply to rsx11m from comment #26)
> (In reply to Ian Neal from comment #25)
> > >+<dt id="secure_connection">secure connection</dt><dd>A connection using
> > >+  <a href="#ssl">SSL</a> or <a href="#tls">TLS</a>.  All communication between
> > >+  your computer and the server is <a href="#encryption">encrypted</a> so that
> > >+  no third party eavesdropping on your connection can read it.  The data
> > >+  itself may not be encrypted but is protected during transmission to and
> > This is confusing, first of all it is encrypted then it may not be? Are you
> > saying that data between your computer and the server is encrypted but after
> > that it might not be? (i.e. between the server and another server).
> 
> InvisibleSmiley wanted the distinction between just encrypting the
> connection and actually encrypting the data, only the latter providing
> "real" security (see comment #10, comment #14 and following).
> 
If you encrypting the connection then you are encrypting the data aren't you?
http://tools.ietf.org/html/rfc5246
Yes, for the duration of the transport. Ben's point was that the server can read it (and may retransmit without encryption, as is typically done between mail MTAs) in contrast to PGP where the message as such is encrypted and (in theory) can only be read by the recipient(s) with the matching key. So, I can either expand on that in the current description or just drop it.
(In reply to rsx11m from comment #29)
> Yes, for the duration of the transport. Ben's point was that the server can
> read it (and may retransmit without encryption, as is typically done between
> mail MTAs) in contrast to PGP where the message as such is encrypted and (in
> theory) can only be read by the recipient(s) with the matching key. So, I
> can either expand on that in the current description or just drop it.

I think it is important that users know that the only bit encrypted is between the client and your mail server, after that it is not encrypted. The client has no control of whether it is encrypted after that.
Ok, I'll try to rephrase that.
> only ... encrypted ... between the client and your mail server, after that it is not encrypted

Yes, that's a much clearer way to express it than I did. Thanks.

(FWIW, it's immaterial whether it's again encrypted after. Once unencrypted by anybody but the recipient, it is no more secret. Snowden taught us that.)

I concur with comment 26 about "bad" certificate, for exactly that reason given.
Attached patch Proposed patch (v6) (obsolete) — Splinter Review
All changes addressed as suggested, with the exception of "bad certificate" as discussed.
Attachment #8427951 - Attachment is obsolete: true
Attachment #8438841 - Flags: review?(iann_bugzilla)
Comment on attachment 8438841 [details] [diff] [review]
Proposed patch (v6)

>+++ b/suite/locales/en-US/chrome/common/help/glossary.xhtml

>+<dt id="secure_connection">secure connection</dt><dd>A connection using
>+  <a href="#ssl">SSL</a> or <a href="#tls">TLS</a>.  All communication between
>+  your computer and the server is <a href="#encryption">encrypted</a> so that
>+  no third party eavesdropping on your connection can read it.  Note that the
>+  data is only encrypted during transmission between your client application
>+  and the server, after that it is no longer encrypted.  To proof its

"prove" rather than "proof"

>+  authenticity to the client, the server needs to identify itself using a
>+  <a href="#certificate">certificate</a>.  A bad certificate can indicate
>+  an attack on the server or the connection, thus it is important to heed
>+  certificate warnings.</dd>
r=me with that fixed.
Attachment #8438841 - Flags: review?(iann_bugzilla) → review+
Attached patch Final patch (v7)Splinter Review
Typo corrected and ready to land on comm-central.
Attachment #8438841 - Attachment is obsolete: true
Attachment #8452010 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/dc57ef9f10b3
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.30
You need to log in before you can comment on or make changes to this bug.