SSL Encryption and HTML

[okoeroo at gmail.com (Oscar Koeroo)]

Hi Paul,

I would advocate for the browsers to issue a warning (error maybe) when
a self signed certificate was used to identify a service in addition to
the warnings if a certificate was signed by an unknown/untrusted CA.

The spoof is usually executed by the use of a self signed certificate
with a subjectAltName:DNS entry in it to tick all the required boxes for
most browsers not to complain (path validation, chain fully validates,
DNS correctness, etc).

Another issue with commercial CAs is that they have commercial gain in
vetting for you by simple checks. They state their company policy, but
don't want to share in detail how they do their internal work. They
don't comply to namespaces with the subject DN lines they issue, how
they operate the CA is their internal business. All very nice and cozy
but I'm very keen on knowing how my trust in them is coming to life in
their operations. Not having that openness makes me suspicious and extra
careful.

Concerning Extended Validation (EV) certificates, that's just a hokes:
Google for "Faking Extended Validation SSL Certificates in Internet
Explorer 7" and you should find a PDF document that describes how it works.

In essence you can make your own certificates with EV and hit the green
light.

The text that claims extra security from the CAs when issuing the more
expensive EV certificates states usually that the CA will do more
careful checking before the certificate is signed by the CA. I still
don't think they'll do a face-to-face check, but they claim to do more
investigation.
This is wrong, because the more careful checking should have been done
in the first place, but that will hurt their business model.


I call this a can't live with and can't live without situation.


        Oscar


Paul Asadoorian wrote:
> My thoughts on SSL:
>
> 1) Spoofing the Certificate - This is successful more often than not,
> and since SSL is based on trust, well bad things can happen.  Remember
> the security conference where they spoofed bogus certs and most people,
> security people at that, accepted the invalid cert?  This is a major
> weakness in the concept of SSL (not necessarily the encryption
> implementation, which is good, just don't get caught using weak ciphers).
>
> 2) Certificate Authorities - If you can own the cert authority, you
> could make a big profit :)  Seriously, ever look at the CA's that are
> trusted in your browser?  There are some shady places in there, and you
> don't necessarily just trust them, you trust however has possession of
> their keys...
>
> 3) Extended Verification Certs - Firefox just recently included this by
> default in version 3, and I think its a good thing, and adds a layer
> (albeit a small one) to the security of SSL.  I like to see the green
> when I go to a web site (especially if its my bank ;)
>
> Cheers,
> Paul
>
> Cody Ray wrote:
> > Do you guys agree with the below statement?
> >
> > Although the login does not occur on a secure HTML page, the login is,
> > in fact, secure. We have all been well trained on how to check for
> > security. We all look down at our status bar at the bottom of the
> > browser to make sure there is a little lock or key that assures us that
> > everything is secure before we send anything. Well now there's a new
> > rule to learn: data can be sent securely even if you don't see these
> > icons of security. When you fill out an information form, or
> > application, or login, etc. you are filling out information on one page
> > and the information is being sent to a second page. We see the security
> > icons when the page that collects the information is secure. The
> > information can be sent securely if the collection page is not secure,
> > but the page where the information is sent to is secure. This is the
> > method we use on home page logins. If you want to assure yourself that
> > the information you are sending is secure and you don't see a security
> > icon, you can view the HTML source code. This may be intimidating for
> > some, but all you have to do is search to find the word "action=." This
> > will show you the location of the page that the information will be sent
> > to. If you see "action='_https://?',_"; you know that it is being sent
> > securely. If you see "action='_http://',_"; you know it is not secure.
> >
> >
> >     Information Encryption
> >
> > Your account information never travels the Internet without encryption
> > protection. When you click on "login", we encrypt your Online Banking ID
> > and password using Secure Sockets Layer (SSL) technology, the highest
> > level of Internet security available. A secure connection is established
> > before your ID and password are transmitted and maintained for the
> > duration of your Online Banking session. 
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Pauldotcom mailing list
> > Pauldotcom at mail.pauldotcom.com
> > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> > Main Web Site: http://pauldotcom.com
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pauldotcom mailing list
> Pauldotcom at mail.pauldotcom.com
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com