On Wed, 26 Jan 2011 14:31:55 +0100
Jochen Schulz wrote:
> Celejar:
> > On Tue, 25 Jan 2011 07:58:28 +0100
> >>
> >> A single core get's used 100% by the kworker thread. But actually it's
> >> not 20MB/s, but 25MB/s while reading (decrypting) and 35MB/s while
> >> writing (encrypting). I just tes
Celejar:
> On Tue, 25 Jan 2011 07:58:28 +0100
>>
>> A single core get's used 100% by the kworker thread. But actually it's
>> not 20MB/s, but 25MB/s while reading (decrypting) and 35MB/s while
>> writing (encrypting). I just tested it again.
>
> So does that mean that your wireless throughput wit
On Tue, 25 Jan 2011 07:58:28 +0100
Jochen Schulz wrote:
> Celejar:
> > On Mon, 24 Jan 2011 22:33:28 +0100
> > Jochen Schulz wrote:
> >
> >> Celejar:
> >>>
> >>> I understand that you're technically adding traffic and processor
> >>> overhead; the question is how much?
> >>
> >> My 1.66GHz ato
On Mon, 24 Jan 2011 16:01:14 -0500, Celejar wrote:
> On Mon, 24 Jan 2011 12:50:34 -0700 david wildgoose wrote:
>
>> On Mon, Jan 24, 2011 at 12:43 PM, Camaleón wrote:
>> > Last time I had to make a "fine-grained" debugging operation over my
>> > network using wireshark I had to "restore-to-life"
Celejar:
> On Mon, 24 Jan 2011 22:33:28 +0100
> Jochen Schulz wrote:
>
>> Celejar:
>>>
>>> I understand that you're technically adding traffic and processor
>>> overhead; the question is how much?
>>
>> My 1.66GHz atom D510 can encrypt/decrypt AES with ~20MByte/s on a single
>> core. Typically,
On Mon, 24 Jan 2011 15:44:47 -0800
GaRaGeD Style wrote:
> yes there is some, that's why load balancers use hardware chips for
> SSL protocol.
a) WPA[2] != SSL
b) We're discussing wireless networking, where there are usually (at
least at the consumer level) only a few clients connected to an A
On Mon, 24 Jan 2011 22:33:28 +0100
Jochen Schulz wrote:
> Celejar:
> >
> > I understand that you're technically adding traffic and processor
> > overhead; the question is how much?
>
> My 1.66GHz atom D510 can encrypt/decrypt AES with ~20MByte/s on a single
> core. Typically, my wifi reaches on
yes there is some, that's why load balancers use hardware chips for
SSL protocol.
On Sun, Jan 23, 2011 at 8:23 PM, Celejar wrote:
> On Sat, 22 Jan 2011 21:00:12 + (UTC)
> Camaleón wrote:
>
> ...
>
>> And WPA2 with AES encryption is considerably slow. There are also
>> drawbacks when you enfo
Celejar:
>
> I understand that you're technically adding traffic and processor
> overhead; the question is how much?
My 1.66GHz atom D510 can encrypt/decrypt AES with ~20MByte/s on a single
core. Typically, my wifi reaches only 10% of that throughput.
Additionally, encryption is usually done by t
On Mon, 24 Jan 2011 19:53:47 + (UTC)
Camaleón wrote:
> On Sun, 23 Jan 2011 23:23:06 -0500, Celejar wrote:
>
> > On Sat, 22 Jan 2011 21:00:12 + (UTC) Camaleón
> > wrote:
> >
> > ...
> >
> >> And WPA2 with AES encryption is considerably slow. There are also
> >> drawbacks when you enfor
On Mon, 24 Jan 2011 12:50:34 -0700
david wildgoose wrote:
> On Mon, Jan 24, 2011 at 12:43 PM, Camaleón wrote:
>
> > On Sun, 23 Jan 2011 23:21:20 -0500, Celejar wrote:
> >
> > > On Sat, 22 Jan 2011 13:37:20 -0600 "Boyd Stephen Smith Jr." wrote:
> > >
> > >> In , Camaleón wrote:
> >
> > >> >I agr
On Sun, 23 Jan 2011 23:23:06 -0500, Celejar wrote:
> On Sat, 22 Jan 2011 21:00:12 + (UTC) Camaleón
> wrote:
>
> ...
>
>> And WPA2 with AES encryption is considerably slow. There are also
>> drawbacks when you enforce to use of the best encryption method.
>
> It is? Do you have either docu
On Mon, Jan 24, 2011 at 12:43 PM, Camaleón wrote:
> On Sun, 23 Jan 2011 23:21:20 -0500, Celejar wrote:
>
> > On Sat, 22 Jan 2011 13:37:20 -0600 "Boyd Stephen Smith Jr." wrote:
> >
> >> In , Camaleón wrote:
>
> >> >I agree. Wired networks are not that exposed to these attacks.
> >>
> >> Not entire
On Sun, 23 Jan 2011 23:21:20 -0500, Celejar wrote:
> On Sat, 22 Jan 2011 13:37:20 -0600 "Boyd Stephen Smith Jr." wrote:
>
>> In , Camaleón wrote:
>> >I agree. Wired networks are not that exposed to these attacks.
>>
>> Not entirely true. On a hubbed network, putting your network card into
>> p
On Mon, 24 Jan 2011 06:16:01 -0600
Nate Bargmann wrote:
> * On 2011 23 Jan 22:24 -0600, Celejar wrote:
> > I know very little about enterprise networking, but are hubs still in
> > actual use today?
>
> Not in the company I work for, We've been very proactive getting rid of
> hubs and putting s
* On 2011 23 Jan 22:24 -0600, Celejar wrote:
> I know very little about enterprise networking, but are hubs still in
> actual use today?
Not in the company I work for, We've been very proactive getting rid of
hubs and putting switches in their place. Interestingly, ten years ago
our network was
On Sat, 22 Jan 2011 21:00:12 + (UTC)
Camaleón wrote:
...
> And WPA2 with AES encryption is considerably slow. There are also
> drawbacks when you enforce to use of the best encryption method.
It is? Do you have either documentation, or personal experience, to
back this up, and to quantify
On Sat, 22 Jan 2011 13:37:20 -0600
"Boyd Stephen Smith Jr." wrote:
> In , Camaleón wrote:
> >On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo M KALINOWSKI wrote:
> >> That's the same reason I was advocating that people should not leave
> >> Wi-Fi (even if public) unencrypted. If traffic is unencrypted
On Fri, 21 Jan 2011 13:20:47 + (UTC)
Camaleón wrote:
...
> Let me put a simple and illustrative example with the Googe search
> engine. To avoid using their "instant" search facility, you can:
>
> - Accept a cookie
> - Use this URI: http://www.google.com/webhp?complete=0&hl=en
Or, of cour
ón
> Subject: Re: Let's talk about HTTPS Everywhere
> To: debian-user@lists.debian.org
> Date: Saturday, January 22, 2011, 9:00 PM
> On Sat, 22 Jan 2011 13:37:20 -0600,
> Boyd Stephen Smith Jr. wrote:
>
> > In ,
> Camaleón wrote:
> >>On Sat, 22 Jan 2011 15:3
On Sat, 22 Jan 2011 13:37:20 -0600, Boyd Stephen Smith Jr. wrote:
> In , Camaleón wrote:
>>On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo M KALINOWSKI wrote:
>>> That's the same reason I was advocating that people should not leave
>>> Wi-Fi (even if public) unencrypted. If traffic is unencrypted, it
In , Camaleón wrote:
>On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo M KALINOWSKI wrote:
>> That's the same reason I was advocating that people should not leave
>> Wi-Fi (even if public) unencrypted. If traffic is unencrypted, it is
>> trivial for anyone to capture session IDs flying in plain text thr
In , Camaleón wrote:
>On Sat, 22 Jan 2011 11:13:31 -0600, Boyd Stephen Smith Jr. wrote:
>> In , Camaleón wrote:
Physical access to the same hardware in a roughly 5 minute window also
allows one to impersonate another user on a Kerberos network; that's
not generally considered insecur
On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo M KALINOWSKI wrote:
> On 01/22/2011 01:39 PM, Camaleón wrote:
>> I wish I had.. sessions carried at server side, hidden fields in forms
>> or variable uri encoding were the common methods used in the past.
>
> I don't think you've fully understood the p
On Sat, 22 Jan 2011 11:13:31 -0600, Boyd Stephen Smith Jr. wrote:
> In , Camaleón wrote:
>>> Physical access to the same hardware in a roughly 5 minute window also
>>> allows one to impersonate another user on a Kerberos network; that's
>>> not generally considered insecure.
>>
>>(...)
>>
>>Not "
On 01/22/2011 01:39 PM, Camaleón wrote:
I wish I had.. sessions carried at server side, hidden fields in forms or
variable uri encoding were the common methods used in the past.
I don't think you've fully understood the problem. The problem is not
that cookies contain sensitive data (well, som
In , Camaleón wrote:
>On Sat, 22 Jan 2011 10:11:39 -0600, Boyd Stephen Smith Jr. wrote:
>> In , Camaleón wrote:
>(...)
>
>>>Or just think about removable flash drive devices with portable versions
>>>of the browsers; the owner logins into his online account (facebook,
>>>gmail, whatever...), check
On Sat, 22 Jan 2011 10:11:39 -0600, Boyd Stephen Smith Jr. wrote:
> In , Camaleón wrote:
(...)
>>Or just think about removable flash drive devices with portable versions
>>of the browsers; the owner logins into his online account (facebook,
>>gmail, whatever...), check the "remember me" option a
In , Camaleón wrote:
>On Fri, 21 Jan 2011 16:14:31 -0600, Boyd Stephen Smith Jr. wrote:
>> In , Camaleón wrote:
>>>Using cookies for tracking/
>>>identifying the user's session can be replaced with another methods or
>>>can require additional security measures for verifying the authenticity
>>>of t
On Fri, 21 Jan 2011 16:14:31 -0600, Boyd Stephen Smith Jr. wrote:
> In , Camaleón wrote:
>>Using cookies for tracking/
>>identifying the user's session can be replaced with another methods or
>>can require additional security measures for verifying the authenticity
>>of the client.
>
> Do you hav
In , Camaleón wrote:
>Using cookies for tracking/
>identifying the user's session can be replaced with another methods or
>can require additional security measures for verifying the authenticity
>of the client.
Do you have a concrete proposal that is simpler than using HTTPS?
Keep in mind that IP
On Fri, 21 Jan 2011 03:21:26 -0600, Dave Sherohman wrote:
> On Thu, Jan 20, 2011 at 03:26:31PM +, Camaleón wrote:
>> In regards to "http cookie hijacking" the first and foremost a
>> programmer would ask himself is "do we really need to *constantly*
>> generate a write/ read operations of the
On Thu, 20 Jan 2011 16:57:52 -0500, Celejar wrote:
> On Thu, 20 Jan 2011 15:26:31 + (UTC) Camaleón wrote:
>
>> In regards to "http cookie hijacking" the first and foremost a
>> programmer would ask himself is "do we really need to *constantly*
>> generate a write/ read operations of the cooki
On Thu, Jan 20, 2011 at 03:26:31PM +, Camaleón wrote:
> In regards to "http cookie hijacking" the first and foremost a programmer
> would ask himself is "do we really need to *constantly* generate a write/
> read operations of the cookies for *all* the tasks?".
Unfortunately, if the site is t
On Thu, 20 Jan 2011 15:26:31 + (UTC)
Camaleón wrote:
> On Wed, 19 Jan 2011 16:09:30 -0500, Celejar wrote:
>
> > On Wed, 19 Jan 2011 17:50:58 + (UTC) Camaleón wrote:
> >
> >> On Wed, 19 Jan 2011 18:07:36 +0100, tv.deb...@googlemail.com wrote:
> >
> > ...
> >
> >> > It is not only the d
On Jan 20, 2011 2:50 PM, "Celejar" wrote:
>
> On Thu, 20 Jan 2011 03:36:03 -0600
> Dave Sherohman wrote:
>
> ...
>
> > Some sites do associate the originating IP address with the session data
> > to help protect against session hijacking, but this is not overly
> > widespread and, even when it is
On Thu, 20 Jan 2011 03:36:03 -0600
Dave Sherohman wrote:
...
> Some sites do associate the originating IP address with the session data
> to help protect against session hijacking, but this is not overly
> widespread and, even when it is employed, it has issues with proxies
> (which can cause mu
On Thu, 20 Jan 2011 03:36:03 -0600, Dave Sherohman wrote:
> On Wed, Jan 19, 2011 at 02:47:11PM +, Camaleón wrote:
>> On Wed, 19 Jan 2011 07:17:58 -0600, Dave Sherohman wrote:
>> > When dealing with sites which use session cookies, "public
>> > navigation" *is* "sensitive data", as every reques
On Wed, 19 Jan 2011 16:09:30 -0500, Celejar wrote:
> On Wed, 19 Jan 2011 17:50:58 + (UTC) Camaleón wrote:
>
>> On Wed, 19 Jan 2011 18:07:36 +0100, tv.deb...@googlemail.com wrote:
>
> ...
>
>> > It is not only the data enclosed inside the cookie which are at risk
>> > here, but the entire se
On Wed, Jan 19, 2011 at 02:47:11PM +, Camaleón wrote:
> On Wed, 19 Jan 2011 07:17:58 -0600, Dave Sherohman wrote:
> > When dealing with sites which use session cookies, "public navigation"
> > *is* "sensitive data", as every request sent will include the cookie(s)
> > which identify you and an
>
> I'm curious - how can one completely guard against a MITM attack
> without using encryption?
>
AFAIK, you don't. I mean, you could setup some type of data checksum with a
seed. But how do you tell bob without eve knowing without encrypting the
seed. BTW, ipsec has a feature like this.
The net
Eduardo M KALINOWSKI:
>
> However, SSL has the added benefit that no one will be spying on
> your traffic, even if it's basically public information that is
> available via other means.
ACK. And additionally, it becomes harder to distinguish "public" from
"private" communication. Why should anyon
On Wed, 19 Jan 2011 17:50:58 + (UTC)
Camaleón wrote:
> On Wed, 19 Jan 2011 18:07:36 +0100, tv.deb...@googlemail.com wrote:
...
> > It is not only the data enclosed inside the cookie which are at risk
> > here, but the entire session on the website you are logged in. Say you
> > log into you
On Qua, 19 Jan 2011, Camaleón wrote:
That sounds like bad programming or a buggy site.
True
There are methods to
prevent such attacks on the server side that involves no encrypted
sessions,
True
but sometimes it is easier (and cheaper) for companies to rely
on completely encrypted session
On Wed, 19 Jan 2011 18:07:36 +0100, tv.deb...@googlemail.com wrote:
> On the 19/01/2011 17:46, Camaleón wrote:
(...)
>> In brief:
>>
>> - Does the cookie contain sensitive/private information? → set/get the
>> cookie using ssl
>>
>> - Does the cookie contain standard/publicly available informa
this might be interesting reading for anyone wondering about https (ssl/tls)
overhead / speed:
http://www.cs.ucr.edu/~bhuyan/papers/ssl.pdf
>> In brief:
>>
>> - Does the cookie contain sensitive/private information? → set/get the
>> cookie using ssl
that depends on the web site.
>>
>> - Does the
On the 19/01/2011 17:46, Camaleón wrote:
> On Wed, 19 Jan 2011 10:53:50 -0500, Curt Howland wrote:
>
>> On Wednesday 19 January 2011, Camaleón was heard to
>> say:
>
>>> Data stored in cookies is not what I understand for "sensitive". What
>>> kind of information do you think are cookies managing
On Wed, 19 Jan 2011 10:53:50 -0500, Curt Howland wrote:
> On Wednesday 19 January 2011, Camaleón was heard to
> say:
>> Data stored in cookies is not what I understand for "sensitive". What
>> kind of information do you think are cookies managing?
>
> Maybe this would be enlightening:
>
> http:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 19 January 2011, Camaleón was heard
to say:
> Data stored in cookies is not what I understand for "sensitive".
> What kind of information do you think are cookies managing?
Maybe this would be enlightening:
http://codebutler.com/firesh
On Wed, 19 Jan 2011 05:52:47 -0800, Kelly Clowers wrote:
> On Wed, Jan 19, 2011 at 04:57, Camaleón wrote:
>> On Wed, 19 Jan 2011 03:29:15 -0800, S Mathias wrote:
>>
>>> 3) Can someone trust this Add-on? Is it safe to install/use?
>>
>> I don't like/trust anoymous (even encrypted) proxy sites.
>
>
On Wed, 19 Jan 2011 07:17:58 -0600, Dave Sherohman wrote:
> On Wed, Jan 19, 2011 at 12:57:48PM +, Camaleón wrote:
>> On Wed, 19 Jan 2011 03:29:15 -0800, S Mathias wrote:
>> > 3) Can someone trust this Add-on? Is it safe to install/use?
>>
>> I don't like/trust anoymous (even encrypted) proxy
On Wed, Jan 19, 2011 at 04:57, Camaleón wrote:
> On Wed, 19 Jan 2011 03:29:15 -0800, S Mathias wrote:
>
>> 3) Can someone trust this Add-on? Is it safe to install/use?
>
> I don't like/trust anoymous (even encrypted) proxy sites.
Why don't you like them (I get not trusting them), and what does th
On Wed, Jan 19, 2011 at 12:57:48PM +, Camaleón wrote:
> On Wed, 19 Jan 2011 03:29:15 -0800, S Mathias wrote:
> > 3) Can someone trust this Add-on? Is it safe to install/use?
>
> I don't like/trust anoymous (even encrypted) proxy sites.
HTTPS Everywhere is not a proxy site, encrypted, anonymou
On Wed, 19 Jan 2011 03:29:15 -0800, S Mathias wrote:
> Ok. It's a Firefox Add-on:
>
> https://www.eff.org/https-everywhere
>
> Questions:
>
> 1) But: Why can't i find it on the offical Firefox Add-ons site?:
> https://addons.mozilla.org/en-US/firefox/
It was there:
http://webcache.googleuserc
On 01/19/2011 07:39 AM, George wrote:
> > Ok. It's a Firefox Add-on:
> > >
> > > https://www.eff.org/https-everywhere
> > >
> > > Questions:
> > >
> > > 2) Did anyone audited the "HTTPS Everywhere" code?
> > > 3) Can someone trust this Add-on? Is it safe to install/use?
and a chrome add-on:
https:
On Wed, Jan 19, 2011 at 1:29 PM, S Mathias wrote:
> Ok. It's a Firefox Add-on:
>
> https://www.eff.org/https-everywhere
>
> Questions:
>
> 2) Did anyone audited the "HTTPS Everywhere" code?
> 3) Can someone trust this Add-on? Is it safe to install/use?
I don't think there's anything to worry abo
Ok. It's a Firefox Add-on:
https://www.eff.org/https-everywhere
Questions:
1) But: Why can't i find it on the offical Firefox Add-ons site?:
https://addons.mozilla.org/en-US/firefox/
2) Did anyone audited the "HTTPS Everywhere" code?
3) Can someone trust this Add-on? Is it safe to install/use
57 matches
Mail list logo
