well httpus seems like a good idea though. Thats the kind of response i was
hoping for. :-)

Maybe browsers would implement that idea in the future. I like that idea a
lot actually. I mean when you login to your linux server the first time with
openssh, you also have to accept the certificate. In the end you have to
trust something somewhere anyway, even if it's just the programmers of the
browser and other software...

I mean who seriously looks through all the source code of the linux kernel
even though it is open source? And even if someone does it (good on them),
do they understand every single line? A back door could be just a few lines
of hard to understand code, that you might skip. It could even be encrypted
and assembly making it very hard to decipher. Who has that much time and
brains? With windows you have to trust M$ even more because you cannot even
look, and i seriously doubt anyone can disassemble the whole windows OS and
read the code. They would not finish in this life time, not even through
50MB of source code i believe. That's a lot!

A warning at the top of the page like as if there were blocked content would
be sufficient until the user clicks to confirm the validity of of the cert.
The warning could just stay until clicked or don't show me again or
something like that.

FF3 atm changes the whole page when a cert is not authenticated. httpus
could have a small warning but leave the site in shape and let it work. This
would also have to be implemented in web servers though, but why not? Seems
like a brilliant idea to me. The warning could also only be displayed once.
I mean you only get warned once that every form gets sent over an unsecured
network anyway. I bet even you security contious have typed in something
somewhere that you maybe shouldn't have :P. I certainly have...

Anyway, good idea, suggest it to the Apache and FF developers and M$ might
follow at some stage if they believe they can make $$ with it or they would
loose some if they didn't :).

Sorry, this is really loosing its (direct) context to PHP.

But maybe you could even do a layer higher than the protocol and make a PHP
module or something that encrypts requests in some way without the
programmer having to be aware of it. Altho i cant think of any way right now
since the browser does the request. Or maybe it could insert smartly a
javascript and attach an event listener to all forms...

How about a js library that even encrypts? One could use RSA or Diffie
Hellman or similar for key exchange, all in js and php and store the session
key in a cookie, just like the session id... Maybe js is a bit slow for
those kind of calculations though. But maybe worth a thought.


Tim-Hinnerk Heuer

Alanis Morissette  - "We'll love you just the way you are if you're

2009/2/17 Colin Guthrie <gm...@colin.guthr.ie>

> 'Twas brillig, and Michael A. Peters at 16/02/09 00:10 did gyre and gimble:
>> Colin Guthrie wrote:
>>> 'Twas brillig, and German Geek at 15/02/09 22:32 did gyre and gimble:
>>>> Please enlighten me why it is so expensive? Is it maybe just the hassle
>>>> of
>>>> setting it up?
>>> The whole thing is about trust. Getting a certificate is nothing if the
>>> system is not backed up by a trust system. If a CA was setup that gave out
>>> certificates willy nilly to all and sundry, then this element of trust is
>>> lost.
>> Cheap CA's do exist. They have crappy web sites and send you all kinds of
>> junk mail etc. if you use them - but they do exist.
>> I might end up just paying godaddy - I think they charge $12.00 / year,
>> but since I already register through them, they already have my address etc.
> Yeah the cheap CA's are IMO actually a problem.
> I (personally) think we should have a new system for this scenario:
> http:// = totally insecure
> https:// = secure and to a reasonable degree of trust (e.g. no $12.00
> certs!)
> httpus:// = secure but no aspect of trust.
> httpus:// would support SSL in exactly the same way as https but the UA
> would simply not display the URL any differently to a standard http
> connection. This would give responsible developers the ability to provide
> SSL services where they only really care about the pipe and not the trust
> aspect.
> The problem with the cheap certs is that people do not see much difference
> to the expensive ones and this leads to the possibility of being hijacked.
> The weakest link is always the end user not knowing any better. The High
> Validation certs used by big companies at least show up differently in FF
> now but if you were to replace it with a hijacked non HV cert, there is
> still a good chance most users would still use it.
> Sadly this isn't going to work without browser support tho' and that's very
> unlikely to happen at all.
> Col
> --
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mandriva.com/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to