Trusting http

How can I be sure that when using an https site that information is
encrypted and secure?

Thanks

A

"not_here.5.species8350@xoxy.net" <not_here.5.species8350@xoxy.net>
writes:

> How can I be sure that when using an https site that information is
> encrypted and secure?

This reads like a homework question, but I'll answer anyway since it's
at least a good homework question.

You can't be sure it's secure, but you can at least have some
assurance its encrypted and is actually the site you think it is if
you specify https:// specifically as the protocol in teh url, and you
use the canonical domain name by which you know the company has its
certs signed. Paying attention to any cert warnings and verifying
them helps as well, as does pruning down your trusted root cert list
to eliminate dodgy ones. That last bit is easier said than done,
though.

Keep in mind that SSL says nothing about the security of the web app
it's connecting to, however, and even the best SSL implementation
won't undo an app that can be trivially sql injected to dump all
database contents, nor will SSL save you if your client computer from
which you're originating the connection has a keylogger, part of a
botnet, or doing all the nastiness that Zeus does.

On 12/30/10 9:08 AM, Regis wrote [in part]:
> "not_here.5.species8350@xoxy.net" <not_here.5.species8350@xoxy.net>
> writes:
>
>> How can I be sure that when using an https site that information is
>> encrypted and secure?
>
> This reads like a homework question, but I'll answer anyway since it's
> at least a good homework question.
>
> You can't be sure it's secure, but you can at least have some
> assurance its encrypted and is actually the site you think it is if
> you specify https:// specifically as the protocol in teh url, and you
> use the canonical domain name by which you know the company has its
> certs signed. Paying attention to any cert warnings and verifying
> them helps as well, as does pruning down your trusted root cert list
> to eliminate dodgy ones. That last bit is easier said than done,
> though.

The Mozilla organization does a thorough review of certificate
authorities (CAs) before including a new certificate in its Network
Security Services (NSS) database for Firefox, Thunderbird, SeaMonkey,
etc. No, Mozilla does not audit the CAs but does require an
independent, professional audit according to published standards.
Certificates are tested by Mozilla to make sure they work and that
revocation lists also work. Finally, each request is subjected to a
public review by users, other CAs, etc. The public reviews are at least
two weeks in duration, sometimes longer when issues and questions arise.
Occasionally, CAs are told to go to the end of the line in order to fix
problems, clarify their documented procedures, get a new audit, etc.

Starting soon, the process will be applied to CAs already in the NSS
database. Each CA will be required to provide the results of an annual
audit and copies of any updated documents. These will be reviewed.

Mozilla's current policy on installing new root certificates into its
NSS database is at
<http://www.mozilla.org/projects/security/certs/policy/>. A draft
revision of this policy is at
<http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/>.
CAs requesting the installation of new root certificates are required
to address a list of problematical practices at
<https://wiki.mozilla.org/CA:Problematic_Practices> prior to the public
reviews of their requests.

No, none of this can guarantee that a CA won't screw up. Furthermore,
Mozilla is somewhat weak in dealing with CAs that seem to screw up badly
or often. However, the process does provide some assurance that only
legitimate CAs get their root certificates installed in the NSS database
for use by Firefox, etc.

--

David E. Ross
<http://www.rossde.com/>

On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.