On 15/01/13 04:53 AM, d...@geer.org wrote:
Oh, I see. So basically they are breaking the implied promise of the
https component of the URL.
In words, if one sticks https at the front of the URL, we are
instructing the browser as our agent to connect securely with the server
using SSL, and to ch
On 1/14/2013 7:39 AM, Harald Hanche-Olsen wrote:
> So let me play devil's advocate for a moment: You could say that the
> browser has two components: One in the phone and one in a server
> somewhere. The two components communicate over a channel provided by
> good old https. The phone component sen
> Oh, I see. So basically they are breaking the implied promise of the
> https component of the URL.
>
> In words, if one sticks https at the front of the URL, we are
> instructing the browser as our agent to connect securely with the server
> using SSL, and to check the certs are in sync.
>
On 14/01/13 14:04 PM, Ben Laurie wrote:
On 14 January 2013 06:11, ianG wrote:
More particularly, banks will have a cause of action against their CA, which
has not apparently batted an eye about the breach of the security model.
Sure, so everyone is doing this. Sure, so there is a really good
On Mon, Jan 14, 2013 at 7:23 AM, Harald Hanche-Olsen
wrote:
> [Ben Laurie (2013-01-14 11:04:11 UTC)]
>
>> How is any CA involved in this?
>
> I was wondering the same thing. But then I went back to the first post
> of this series, which mentions [1] as the primary source. The actual
> evidence is
So let me play devil's advocate for a moment: You could say that the
browser has two components: One in the phone and one in a server
somewhere. The two components communicate over a channel provided by
good old https. The phone component sends the request to the server
component, which in turn for
[Harald Hanche-Olsen (2013-01-14 12:23:31 UTC)]
> [Ben Laurie (2013-01-14 11:04:11 UTC)]
>
> > How is any CA involved in this?
>
> I was wondering the same thing. But then [...]
But then I may have responded too quickly: There is no fake
certificate for google.com in there, as you might have
[Ben Laurie (2013-01-14 11:04:11 UTC)]
> How is any CA involved in this?
I was wondering the same thing. But then I went back to the first post
of this series, which mentions [1] as the primary source. The actual
evidence is seen in [2], linked to from [1].
[1] http://gaurangkp.wordpress.com/20
On 14 January 2013 06:11, ianG wrote:
> On 13/01/13 22:47 PM, Jeffrey Walton wrote:
>>
>> On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari wrote:
>>>
>>>
>>> On Jan 12, 2013, at 4:27 AM, ianG wrote:
>>>
On 11/01/13 02:59 AM, Jon Callas wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
>>>
On 13/01/13 22:47 PM, Jeffrey Walton wrote:
On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari wrote:
On Jan 12, 2013, at 4:27 AM, ianG wrote:
On 11/01/13 02:59 AM, Jon Callas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
The Amazon FAQ for Silk did at least say:
"We will establi
Jeffrey Walton wrote:
On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari wrote:
On Jan 12, 2013, at 4:27 AM, ianG wrote:
On 11/01/13 02:59 AM, Jon Callas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
The Amazon FAQ for Silk did at least say:
"We will establish a secure connection f
On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari wrote:
>
> On Jan 12, 2013, at 4:27 AM, ianG wrote:
>
>> On 11/01/13 02:59 AM, Jon Callas wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> ...
>
> The Amazon FAQ for Silk did at least say:
> "We will establish a secure connection
On Jan 12, 2013, at 4:27 AM, ianG wrote:
> On 11/01/13 02:59 AM, Jon Callas wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Others have said pretty much the same in this thread; this isn't an MITM
>> attack, it's a proxy browsing service.
>>
>> There are a number of "optimize
On Sat, Jan 12, 2013 at 6:11 PM, Kevin W. Wall wrote:
> On Sat, Jan 12, 2013 at 4:37 PM, Jeffrey Walton wrote:
>> On Sat, Jan 12, 2013 at 2:35 PM, Kevin W. Wall
>> wrote:
> [snip]
>>> Whoa...hold on there Jeff. I'm hoping that I'm misunderstanding your
>>> last statement about what the pen test
On Sat, Jan 12, 2013 at 4:37 PM, Jeffrey Walton wrote:
> On Sat, Jan 12, 2013 at 2:35 PM, Kevin W. Wall wrote:
[snip]
>> Whoa...hold on there Jeff. I'm hoping that I'm misunderstanding your
>> last statement about what the pen testers did to "destroy a secure
>> channel".
>>
>> Are you implying t
On Sat, Jan 12, 2013 at 2:35 PM, Kevin W. Wall wrote:
> Relevant to this thread, but OT to the charter of this list.
>
> On Sat, Jan 12, 2013 at 5:46 AM, Jeffrey Walton wrote:
>> On Sat, Jan 12, 2013 at 4:27 AM, ianG wrote:
>>> On 11/01/13 02:59 AM, Jon Callas wrote:
-BEGIN PGP SIG
Jon Callas wrote:
> (The quibble I have is over partial security. My quibble is that lots of
> partial
> security systems label the partial security as being worse than no security.
> I believe that partial security is always better than no security.)
Except when it is marketed as just "secure"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 12, 2013, at 1:27 AM, ianG wrote:
> Oh, I see. So basically they are breaking the implied promise of the https
> component of the URL.
>
> In words, if one sticks https at the front of the URL, we are instructing the
> browser as our agent
Relevant to this thread, but OT to the charter of this list.
On Sat, Jan 12, 2013 at 5:46 AM, Jeffrey Walton wrote:
> On Sat, Jan 12, 2013 at 4:27 AM, ianG wrote:
>> On 11/01/13 02:59 AM, Jon Callas wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Others have said pretty
On Thu, Jan 10, 2013 at 4:53 PM, ianG wrote:
> On 7/01/13 14:33 PM, ianG wrote:
>>
>> ...
>
> http://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/
>
> Pictures above seem to indicate VeriSign as the CA, but whether that means
> they know about the MITMing is not clear.
Might as well pin it
On Sat, Jan 12, 2013 at 4:27 AM, ianG wrote:
> On 11/01/13 02:59 AM, Jon Callas wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Others have said pretty much the same in this thread; this isn't an MITM
>> attack, it's a proxy browsing service.
>>
>> There are a number of "optimi
On 11/01/13 02:59 AM, Jon Callas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Others have said pretty much the same in this thread; this isn't an MITM
attack, it's a proxy browsing service.
There are a number of "optimized" browsers around. Opera Mini/Mobile, Amazon Silk for the
Kindl
On Fri, Jan 11, 2013 at 12:20 PM, Thierry Moreau
wrote:
> Jeffrey Walton wrote:
>>>
>>>
>
> More seriously, I agree that the questions raised by Jeffrey are relevant,
> and I support his main point. End-to-end security should make some sense,
> even today.
Also: are they doing it over WiFi or
On Jan 11, 2013, at 3:16 PM, Thierry Moreau wrote:
> John Kemp wrote:
>> [...] the _spirit_ of end-to-end semantics is violated here, I believe [...]
>
> Personally, I am not a spiritual cryptography believer.
For the purposes of HTTPS, you don't have to be; the encryption works as
specified.
John Kemp wrote:
[...] the _spirit_ of end-to-end semantics is violated here, I believe [...]
Personally, I am not a spiritual cryptography believer.
--
- Thierry Moreau
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit
On Thu, Jan 10, 2013 at 6:59 PM, Jon Callas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Others have said pretty much the same in this thread; this isn't an MITM
> attack, it's a proxy browsing service.
>
> There are a number of "optimized" browsers around. Opera Mini/Mobile, Amaz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 10, 2013, at 4:47 PM, Peter Gutmann wrote:
> Jon Callas writes:
>
>> Others have said pretty much the same in this thread; this isn't an MITM
>> attack, it's a proxy browsing service.
>
> Exactly. Cellular providers have been doing this f
On 11/01/13 21:57 PM, Jeffrey Walton wrote:
On Fri, Jan 11, 2013 at 12:20 PM, Thierry Moreau
wrote:
Jeffrey Walton wrote:
More seriously, I agree that the questions raised by Jeffrey are relevant,
and I support his main point. End-to-end security should make some sense,
even today.
I think
On Jan 11, 2013, at 1:53 PM, Jeffrey Walton wrote:
> One of the things I find most befuddling: the industry has conditioned
> many folks to accept this sort of thing as "normal"
> (Proxy/Interception on a "secure' channel"), even when those same
> folks know better. Its seems to be a repeat of bro
On Fri, Jan 11, 2013 at 12:20 PM, Thierry Moreau
wrote:
> Jeffrey Walton wrote:
>>>
>>> ...
>> Perhaps they should be using the evil bit in the TCP/IP header to
>> indicate someone (or entity) is tampering with the secure channel?
>> https://tools.ietf.org/html/rfc3514.
>
> That's an April 1st RFC
On Fri, Jan 11, 2013 at 1:39 PM, Adam Back wrote:
> For http there is a mechanism for cache security as this is an issue that
> does come up (you do not want to cache security information or responses
> with security information in them, eg cookies or information related to one
> user and then hav
For http there is a mechanism for cache security as this is an issue that
does come up (you do not want to cache security information or responses
with security information in them, eg cookies or information related to one
user and then have the proxy cache accidentally send that to a different
us
Jeffrey Walton wrote:
How do we teach developers to differentiate between the good
"men-in-the-middle" vs the bad "man-in-the-middle"?
According to another post by Peter, good ones would be based on
anonymous D-H.
Perhaps they should be using the evil bit in the TCP/IP header to
indicate
On Fri, Jan 11, 2013 at 10:04 AM, Jeffrey Walton wrote:
> On Thu, Jan 10, 2013 at 7:47 PM, Peter Gutmann
> wrote:
>> Jon Callas writes:
>>
>>>Others have said pretty much the same in this thread; this isn't an MITM
>>>attack, it's a proxy browsing service.
>>
>> Exactly. Cellular providers have
On Thu, Jan 10, 2013 at 7:47 PM, Peter Gutmann
wrote:
> Jon Callas writes:
>
>>Others have said pretty much the same in this thread; this isn't an MITM
>>attack, it's a proxy browsing service.
>
> Exactly. Cellular providers have been doing this for ages, it's hardly news.
>
> (Well, OK, given h
Jon Callas writes:
>Others have said pretty much the same in this thread; this isn't an MITM
>attack, it's a proxy browsing service.
Exactly. Cellular providers have been doing this for ages, it's hardly news.
(Well, OK, given how surprised people seem to be, perhaps it should be news in
ord
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Others have said pretty much the same in this thread; this isn't an MITM
attack, it's a proxy browsing service.
There are a number of "optimized" browsers around. Opera Mini/Mobile, Amazon
Silk for the Kindle Fire, and likely others. Lots of old "WA
Good point. My thinking is:
First how do you know it's Nokia that really posted this?
Second read the post carefully. They are not admitting to anything.
There is an implied - "if we needed to it would be secure" or
something along those lines which means exactly nothing. this second
thing makes
On Thu, Jan 10, 2013 at 6:02 PM, Krassimir Tzvetanov
wrote:
> What the wireshark captures are showing is the OVI app talking to
> their cloud (I would speculate the app is just updating its catalog or
> something of that sort).
>
> I did not see even a mention of the word fingerprint. Let alone
>
What the wireshark captures are showing is the OVI app talking to
their cloud (I would speculate the app is just updating its catalog or
something of that sort).
I did not see even a mention of the word fingerprint. Let alone
comparing the "fake" with the "real". Do I need to continue :)
Krassi
When you look at what the Nokia Browser does in the non-TLS case you see
that the Nokia Browser like the Kindle Browser and Opera Mobile use a
dedicated proxy server to avoid DNS latency and permit
cached/compressed/reformatted web pages to be transmitted to the mobile
device. This is
performed by
On Thu, Jan 10, 2013 at 4:53 PM, ianG wrote:
> On 7/01/13 14:33 PM, ianG wrote:
>>
>> On 7/01/13 13:25 PM, Ben Laurie wrote:
>
> ...
> Just on that theme of multiple attacks from different vectors leading to
> questions at the systemic level, another certificate failure just got posted
> on slashd
On 7/01/13 14:33 PM, ianG wrote:
On 7/01/13 13:25 PM, Ben Laurie wrote:
This is a bizarre statement in the face of Diginotar.
http://wiki.cacert.org/Risk/History shows no real correlation in
attacks. There are many many possible attacks, so...
Just on that theme of multiple attacks from d
43 matches
Mail list logo
