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 with
On Wed, 26 Jan 2011 14:31:55 +0100
Jochen Schulz m...@well-adjusted.de 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
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 an old (and
On Tue, 25 Jan 2011 07:58:28 +0100
Jochen Schulz m...@well-adjusted.de wrote:
Celejar:
On Mon, 24 Jan 2011 22:33:28 +0100
Jochen Schulz m...@well-adjusted.de wrote:
Celejar:
I understand that you're technically adding traffic and processor
overhead; the question is how much?
* 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 Mon, 24 Jan 2011 06:16:01 -0600
Nate Bargmann n...@n0nb.us 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
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 pan.2011.01.22.18.58...@gmail.com, Camaleón wrote:
I agree. Wired networks are not that exposed to these attacks.
Not entirely true. On a hubbed network, putting your
On Mon, Jan 24, 2011 at 12:43 PM, Camaleón noela...@gmail.com 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 pan.2011.01.22.18.58...@gmail.com, Camaleón wrote:
I agree. Wired networks are not that exposed to
On Sun, 23 Jan 2011 23:23:06 -0500, Celejar wrote:
On Sat, 22 Jan 2011 21:00:12 + (UTC) Camaleón noela...@gmail.com
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
On Mon, 24 Jan 2011 12:50:34 -0700
david wildgoose david.wildgo...@gmail.com wrote:
On Mon, Jan 24, 2011 at 12:43 PM, Camaleón noela...@gmail.com 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
On Mon, 24 Jan 2011 19:53:47 + (UTC)
Camaleón noela...@gmail.com wrote:
On Sun, 23 Jan 2011 23:23:06 -0500, Celejar wrote:
On Sat, 22 Jan 2011 21:00:12 + (UTC) Camaleón noela...@gmail.com
wrote:
...
And WPA2 with AES encryption is considerably slow. There are also
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 the
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 cele...@gmail.com wrote:
On Sat, 22 Jan 2011 21:00:12 + (UTC)
Camaleón noela...@gmail.com wrote:
...
And WPA2 with AES encryption is considerably slow. There are
On Mon, 24 Jan 2011 22:33:28 +0100
Jochen Schulz m...@well-adjusted.de 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
On Mon, 24 Jan 2011 15:44:47 -0800
GaRaGeD Style gara...@gmail.com 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
Celejar:
On Mon, 24 Jan 2011 22:33:28 +0100
Jochen Schulz m...@well-adjusted.de 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.
On Fri, 21 Jan 2011 13:20:47 + (UTC)
Camaleón noela...@gmail.com 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=0hl=en
On Sat, 22 Jan 2011 13:37:20 -0600
Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:
In pan.2011.01.22.18.58...@gmail.com, 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
On Sat, 22 Jan 2011 21:00:12 + (UTC)
Camaleón noela...@gmail.com 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
On Fri, 21 Jan 2011 16:14:31 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.21.12.44...@gmail.com, 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
In pan.2011.01.22.15.39...@gmail.com, Camaleón wrote:
On Fri, 21 Jan 2011 16:14:31 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.21.12.44...@gmail.com, Camaleón wrote:
Using cookies for tracking/
identifying the user's session can be replaced with another methods or
can require additional
On Sat, 22 Jan 2011 10:11:39 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.22.15.39...@gmail.com, 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
In pan.2011.01.22.16.44...@gmail.com, Camaleón wrote:
On Sat, 22 Jan 2011 10:11:39 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.22.15.39...@gmail.com, Camaleón wrote:
(...)
Or just think about removable flash drive devices with portable versions
of the browsers; the owner logins into his
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,
On Sat, 22 Jan 2011 11:13:31 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.22.16.44...@gmail.com, 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
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
In pan.2011.01.22.18.22...@gmail.com, Camaleón wrote:
On Sat, 22 Jan 2011 11:13:31 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.22.16.44...@gmail.com, Camaleón wrote:
Physical access to the same hardware in a roughly 5 minute window also
allows one to impersonate another user on a
In pan.2011.01.22.18.58...@gmail.com, 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
On Sat, 22 Jan 2011 13:37:20 -0600, Boyd Stephen Smith Jr. wrote:
In pan.2011.01.22.18.58...@gmail.com, 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
...@gmail.com
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 pan.2011.01.22.18.58...@gmail.com,
Camaleón wrote:
On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo
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 to
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 cookies for
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 cookies
In pan.2011.01.21.12.44...@gmail.com, 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
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 attacker
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 session on the
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 request sent will
On Thu, 20 Jan 2011 03:36:03 -0600
Dave Sherohman d...@sherohman.org 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
On Jan 20, 2011 2:50 PM, Celejar cele...@gmail.com wrote:
On Thu, 20 Jan 2011 03:36:03 -0600
Dave Sherohman d...@sherohman.org wrote:
...
Some sites do associate the originating IP address with the session data
to help protect against session hijacking, but this is not overly
On Thu, 20 Jan 2011 15:26:31 + (UTC)
Camaleón noela...@gmail.com 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
On Wed, Jan 19, 2011 at 1:29 PM, S Mathias smathias1...@yahoo.com 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
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:
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:
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, anonymous,
On Wed, Jan 19, 2011 at 04:57, Camaleón noela...@gmail.com 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
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 sites.
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.
Why don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 19 January 2011, Camaleón noela...@gmail.com 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:
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:
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?
Maybe this
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 cookie
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 information → no
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
On Wed, 19 Jan 2011 17:50:58 + (UTC)
Camaleón noela...@gmail.com 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
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 anyone want
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
56 matches
Mail list logo
