> Now, when I send my sensitives data to that party, that party could always
> turn around and give my data to my enemies, put it on a road-side bill
> board, or disseminate it in various ways of which I don't approve.
> Having an authenticated certificate doesn't assure me that the party won't
> d
I'm changing the subject of this thread to a more meaningful one.
Michael Vincent van Rantwijk, MultiZilla wrote:
> Nelson B wrote:
>> Most users of cryptography (all forms, not just https or SSL) mistakenly
>> assume that "encrypted" means that no one but the intended recipient can
>> read the t
Jeremy Morton wrote:
>
> Well, I think if FF3 switches completely to the new identity info model
> as proposed in bug #, then hopefully yes they will. Basically, if there
> aint a big green section in the URLbar with a name you trust in it,
> don't use it for, say, online banking. However what
Michael Vincent van Rantwijk, MultiZilla wrote:
[...]
>
> What is the key difference here? Why can't you read authenticated
> encrypted data but unauthenticated encrypted data?
>
> p.s. you are assuming that the server certificate is safe at all time,
> which it isn't.
UserKeyM
Jeremy Morton wrote:
> Nelson B wrote:
> [...]
>> Since the users tend to understand any such indicator as meaning that
>> their traffic cannot be read in the clear except by the intended
>> recipient, we want the indicators to mean exactly that. That is why
>> we do not propose to offer an indica
Nelson B wrote:
> Jeremy Morton wrote:
>> Nelson B wrote:
>>> Jeremy Morton wrote:
Re: bugzilla bug #383183 comment #52:
So just to confirm, you're saying that there is no difference in
security between submitting a username/password via HTTP and via HTTPS
with a self-sig
Nelson B wrote:
[...]
> Since the users tend to understand any such indicator as meaning that
> their traffic cannot be read in the clear except by the intended
> recipient, we want the indicators to mean exactly that. That is why
> we do not propose to offer an indication of encryption without au
Jeremy Morton wrote:
> Nelson B wrote:
>> Jeremy Morton wrote:
>>> Re: bugzilla bug #383183 comment #52:
>>>
>>> So just to confirm, you're saying that there is no difference in
>>> security between submitting a username/password via HTTP and via HTTPS
>>> with a self-signed SSL cert?
>> http is
Eddy Nigg (StartCom Ltd.) wrote:
[...]
> Jeremy, I think one of the problems with self-signed certificates is
> what I call "warning-popup-click-away-effect". People simply got used to
> click through the warnings, which in some way deflated the SSL
> authentication model further (speaking here
That should have said bug #383183.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Jeremy Morton wrote:
> Nelson B wrote:
>> http is vulnerable to passive attack ("sniffers").
>> https with self-signed certs is not vulnerable to passive attack.
>> That is the only essential difference.
>> Both are vulnerable to active attack.
>> Both are *trivially* attacked by MITM attackers.
>>
Nelson B wrote:
> Jeremy Morton wrote:
>> Re: bugzilla bug #383183 comment #52:
>>
>> So just to confirm, you're saying that there is no difference in
>> security between submitting a username/password via HTTP and via HTTPS
>> with a self-signed SSL cert?
>
> http is vulnerable to passive attac
Jeremy Morton wrote:
> Re: bugzilla bug #383183 comment #52:
>
> So just to confirm, you're saying that there is no difference in
> security between submitting a username/password via HTTP and via HTTPS
> with a self-signed SSL cert?
http is vulnerable to passive attack ("sniffers").
https with
Re: bugzilla bug #383183 comment #52:
So just to confirm, you're saying that there is no difference in
security between submitting a username/password via HTTP and via HTTPS
with a self-signed SSL cert?
Best regards,
Jeremy Morton (Jez)
___
dev-tech-
14 matches
Mail list logo
