.gov site with invalid cert
Ryan Trinder
Asmodian X
authority.
It would make sense in that why would you trust a commercial entity
who through mergers and acquisitions could become comprised as we have
seen with the firefox certificate issue.
The next step is including their certificate with popular browsers.
The Perspectives FF plugin overrides the error message when I go
there.
-=- AX -=-
On Nov 2, 10:37 am, Ryan Trinder <tgueri...@gmail.com> wrote:
> https://www.tripwire.dhs.gov/IED/appmanager/IEDPortal/IEDDesktop?_nfp...
Doug Kelly
That is an interesting idea... to have a root CA included takes a lot of money (government has this) and some pretty strict safeguards on the CA itself (not so sure they have this, but wouldn't be hard to develop). I also think they should be allowed to sign for .gov / .mil only, though (or similar)... I know there was talk a while back about court-ordered SSL forgery.
It would be good from the standpoint of verifying it is indeed the US government... but their CPS would have to specifically bar any abuses, and be routinely audited by an outside entity.
That said, anyone remember the .mil (or was it .gov too?) TLD compromise a few years back?
Doug
Billy Crook
> https://www.tripwire.dhs.gov/IED/appmanager/IEDPortal/IEDDesktop?_nfpb=true&_pageLabel=LOGIN
it's https://www.tripwire.dhs.gov or technically it's 199.124.28.7
that's misconfigured, since a host has to negotiate ssl before it may
discuss the requested domain name.
That's odd. Firefox says 'sec_error_unknown_issuer', which implies
self-signed, but "openssl s_client -connect www.tripwire.dhs.gov:443"
just sits at CONNECTED(00000003) and never gets a cert at all from the
server. So this is probably a misconfiguration. Or maybe it's
waiting for a client certificate.
Even more curious, the IP appears to be owned by a private
corporation, K2Share, not by the government. Maybe that's why they
don't have a government ssl certificate.
For the record, the US government does maintain, several SSL
Certificate Authorities. Most military computers have them installed
at image time. I imagine everything on sipurnet uses those CAs, and
has the commercial CAs removed.
The only way SSL can actually hold any water is by removing all CAs
except those you personally know and trust. Simply ADDING, ONE ca
that you DO trust is not enough.
Doug Kelly
This is indeed true. I was talking about a public, trusted root CA for external websites.
Also, TLS does allow for Server Name Indication--so you can negotiate hostnames along with the handshake. Support isn't great yet, but it is growing.
Doug
Billy Crook
> This is indeed true. I was talking about a public, trusted root CA for
> external websites.
>
> Also, TLS does allow for Server Name Indication--so you can negotiate
> hostnames along with the handshake. Support isn't great yet, but it is
> growing.
Oh yeah. I think that was one of the original ideas: that certificate
trust could be rooted geographically+governmentally hence why you
often see 'OU=''s indicating country, state, city, etc.
You can not as a client, select, which hostname you want until AFTER
the handshake. So the certificate the server offers during the
handshake must match all possible hostnames you could be asking for.
Unless I'm wrong. It'd be nice if I was. But I bet that would break
compatability, as well as open security vulnerabilities.
For example: I do not want an attacker to know what hostname I'm
connecting to at a given IP address. If that was sent before TLS was
established, the attacker could know that.
Doug Kelly
True. X.509 added subjectAltNames to send a list of acceptable domains, but SNI is a standard for agreeing upon the hostname very early on in the handshake, before certificates are sent. It did require a break in the protocol, thus is only a part of TLS (SSL as we knew it is dead anyway; Mozilla killed SSLv2 some time ago). Server support for SNI is in both mod_ssl and mod_gnutls, and most clients support it... except for XP clients. Go figure.
Doug