Nelson B Bolyard wrote: > OK, I was too flippant, but I'm serious about wanting an alternative > to https, something that means security not good enough for financial > transactions, but OK for your private home router/server. > > Nelson B Bolyard wrote, On 2008-10-20 15:07: >> Ian G wrote, On 2008-10-20 13:28: > >>> (e.g., we do agree that we'd like to write something that says "for >>> high value commerce, use XXXX" ... except we don't know what XXXX is.) >> I keep wondering about that.
Actually above I was referring to online banking. Right now,
browsers aren't up to it. That's a big concern. I have been toying
with NoScript, but it requires too much interaction for the masses
to follow.
>> Lots of people seem to agree that they want
>> some kind of half-vast SSL, providing some encryption, but no assurance
>> that the party to whom they're connected is who they intended it to be.
>> No protection against MITM, just a warm fuzzy feeling that "well, at least
>> we're using encryption". I think the term "security theater" applies.
Well, from high to low ...
There are possibilities. One is the server-side self-signed certs,
which would generally prefer KCM to be useful, so add Petnames.
This is ok for small sites, small communities, but valuable there as
compromised boxes are a pain.
The second is the ADH style where it just boots up in promiscuous
mode and we hope the person we're with is the one we wanted.
Personally I think this is not worth worrying about; if KCM is
coming then self-signed certs would be more bang-for-buck.
The alternate aspect is that once in ADH, we could upgrade to
certificate-based security if needed. E.g., for a login; this is
more or less what all online banking does. Sometimes it then falls
back, which would be fine if the cert-based step confirmed the ADH
key exchange.
However, caveats: just idle late night thoughts. Also, this is all
pie in the sky. There is little ability to change the protocols or
get these things implemented, these things are set in stone. We
can't even get the "approved" stuff implemented, let alone new stuff.
>> How do we give them that in a way that clearly distinguishes between that
>> and real authenticated connections? I think there are (at least) two parts
>> to the puzzle:
>>
>> a) some way to convey to the browser that the EXPECTED amount of security
>> is low, so the browser won't try to impose all the usual high security
>> requirements on the connection (e.g. not impose strong authentication
>> requiremetns) and hence won't show any warnings. I'm thinking we need an
>> alterantive to https for this.
Well, we had in the past suggested that a white URL bar would be
fine for that.
(But now that is being used for full CA-authenticated SSL.)
Also, black is a neutral colour, so invert the URL bar, perhaps?
If you wanted a padlock replacement that was kind of weak, you could
put a fig leaf ... although if drawn too small it might look like
that other popular weed :)
Actually the current display gives much more info by clicking, so
you could just put the "lowsec" rating in there, no?
> serious alternatives to https wanted.
https is generally thought to be 443 and/or SSL. Are you saying you
want to vary those?
A lot depends on what you are trying to do ("requirements") and how
much you want to re-use the existing SSL infrastructure.
For my money, I would not drift at all from the SSL infrastructure,
and I would add in an upgrade path; the goal would be to get more
people upgrading to full SSL, rather than wholescale rewrites.
Also, bear in mind the maxim: all protocols divide naturally into
two parts. Distribute this key, then, Trust this key completely.
So, there essence is to break it into two areas, being distro the
cert or key in cleartext / http, cache it, then upgrade and encrypt.
E.g., distro the key/cert/port in the HTTP headers, or have the
client do a GET of a wellknown file. Then have the client do an
automatic upgrade.
Just some thoughts.
>> b) some unmistakeable blatantly obvious way to show the user that this
>> site is not using security that's good enough for banking but,
>
> Serious chrome ideas wanted.
Yes, this part is harder.
>> With such an alternative to regular https, we could raise the bar on https
>> certs (stop allowing overrides) while still offering an alternative for
>> those who want it.
Certainly, having a series of steps up that allows most sites to
settle for "medium" and those that need it to stay at "high" is a
good idea. As long as we keep an eye on easy upgrades, then it
should help everyone.
Oh, and implement TLS/SNI. You already have? Darn, someone must be
holding back!
iang
PS: it's httpd team at apache. They just missed the release, again.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
