Re: Let's talk about HTTPS Everywhere
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 encryption enabled is CPU-bound, and that you'd be getting better throughput with a more powerful CPU (or without encryption)? No. The numbers I posted were about disk encryption. They were just meant to illustrate what throughput is possible with AES if it is done by a comparably slow CPU (Atom D510, 1.66GHz). With WPA2/AES you have significantly less throughput (typically 10%) and, as far as I know, wifi encrpytion is done by the hardware and not the host CPU. But even if it's done on the host CPU: my numbers show that you really don't need to care about that very much, as long as your system isn't older than, say, 6-8 years. (Disclaimer: I am unsure whether WPA2 with AES actually performs the same as LUKS using AES. But my guess is that it's not far off.) J. -- I am not scared of death but terrified of people in Tommy Hilfiger sweatshirts. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Let's talk about HTTPS Everywhere
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 just tested it again. So does that mean that your wireless throughput with encryption enabled is CPU-bound, and that you'd be getting better throughput with a more powerful CPU (or without encryption)? No. The numbers I posted were about disk encryption. They were just meant to illustrate what throughput is possible with AES if it is done by a comparably slow CPU (Atom D510, 1.66GHz). With WPA2/AES you have significantly less throughput (typically 10%) and, as far as I know, wifi encrpytion is done by the hardware and not the host CPU. But even if it's done on the host CPU: my numbers show that you really don't need to care about that very much, as long as your system isn't older than, say, 6-8 years. (Disclaimer: I am unsure whether WPA2 with AES actually performs the same as LUKS using AES. But my guess is that it's not far off.) Okay - thanks for the clarification. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126093738.d566a3d2.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 dusty) hub that came with our DSL device... back in 2000 :-P Port monitoring is something thats useful in troubleshooting network related problems on networks using switches, thought I think your switch needs to support it. Yes. IIUC, you may be confusing two scenarios: with hubs, all traffic always gets sent out to all connected systems, so monitoring is straightforward. With switches, traffic is normally sent only to the target hosts, so to monitor general network traffic from a specific host, mirroring is needed, and it is indeed a special feature of some switches: http://en.wikipedia.org/wiki/Port_mirroring True, but David is also right. As you point out, there are some enterprise switches that implement a monitoring port (an special catch- all-data port that when enabled, it captures all the traffic). Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.25.12.12...@gmail.com
Re: Let's talk about HTTPS Everywhere
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? 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 network adapter in hardware, as far as I know. The host CPU shouldn't be stressed by that. Thanks. What's the CPU usage like while doing AES on 20Mb? 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 encryption enabled is CPU-bound, and that you'd be getting better throughput with a more powerful CPU (or without encryption)? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125145546.05cca16f.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
* 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 predominantly Token Ring. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://n0nb.us/index.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124121601.gb14...@n0nb.us
Re: Let's talk about HTTPS Everywhere
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 putting switches in their place. Interestingly, ten years ago our network was predominantly Token Ring. That's pretty much what I thought. I know that in the consumer / SOHO area, one never sees hubs for sale (yes, I know that if you look carefully, you can find them). Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124083817.a129ce5c.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. I know very little about enterprise networking, but are hubs still in actual use today? 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 dusty) hub that came with our DSL device... back in 2000 :-P Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.24.19.43...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 these attacks. Not entirely true. On a hubbed network, putting your network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. I know very little about enterprise networking, but are hubs still in actual use today? 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 dusty) hub that came with our DSL device... back in 2000 :-P Port monitoring is something thats useful in troubleshooting network related problems on networks using switches, thought I think your switch needs to support it. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.24.19.43...@gmail.com -- David Wildgoose
Re: Let's talk about HTTPS Everywhere
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 either documentation, or personal experience, to back this up, and to quantify the performance hit? I've never noticed one, but I've not actually benchmarked. Personal experience with wpa2... while I don't discard it was a specific problem/incompatibility with the wireless card chipset in use and the AP, heck, should you add a security layer you are adding more traffic (data) that need to be proccessed (encoded/decoded) by both, the host AP and client. Besides, if you experience additional problems with coberture (long distance between the AP and the client) or interferences (saturated channel spectrum) then the recipe for a slow connection is served :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.24.19.53...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 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 network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. I know very little about enterprise networking, but are hubs still in actual use today? 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 dusty) hub that came with our DSL device... back in 2000 :-P Port monitoring is something thats useful in troubleshooting network related problems on networks using switches, thought I think your switch needs to support it. IIUC, you may be confusing two scenarios: with hubs, all traffic always gets sent out to all connected systems, so monitoring is straightforward. With switches, traffic is normally sent only to the target hosts, so to monitor general network traffic from a specific host, mirroring is needed, and it is indeed a special feature of some switches: http://en.wikipedia.org/wiki/Port_mirroring Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124160114.6c6dc0a2.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 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 the performance hit? I've never noticed one, but I've not actually benchmarked. Personal experience with wpa2... while I don't discard it was a specific problem/incompatibility with the wireless card chipset in use and the AP, heck, should you add a security layer you are adding more traffic (data) that need to be proccessed (encoded/decoded) by both, the host AP and client. I understand that you're technically adding traffic and processor overhead; the question is how much? Given the (relatively low) amounts of data going over WiFi, and the capabilities of modern hardware, I'm not at all sure that the overhead is really all that noticeable. Besides, if you experience additional problems with coberture (long distance between the AP and the client) or interferences (saturated channel spectrum) then the recipe for a slow connection is served :-) But these will be problems even without encryption - how much worse will they really get with it? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124160358.a45a14df.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 network adapter in hardware, as far as I know. The host CPU shouldn't be stressed by that. J. -- I no longer believe my life will be long, happy, interesting or fulfilled [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Let's talk about HTTPS Everywhere
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 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 the performance hit? I've never noticed one, but I've not actually benchmarked. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123232306.cffeb07b.cele...@gmail.com -- $ echo scale=100; 4*a(1) | bc -l -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikHDByp0+DeLX0U11A-gtMERXnj=ulyevjxf...@mail.gmail.com
Re: Let's talk about HTTPS Everywhere
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 wifi reaches only 10% of that throughput. Additionally, encryption is usually done by the network adapter in hardware, as far as I know. The host CPU shouldn't be stressed by that. Thanks. What's the CPU usage like while doing AES on 20Mb? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124203247.9b22ab1f.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 connected to an AP. Load balancers are presumably useful with large-scale commercial applications. 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 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 the performance hit? I've never noticed one, but I've not actually benchmarked. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123232306.cffeb07b.cele...@gmail.com -- $ echo scale=100; 4*a(1) | bc -l Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124205342.d17ccd0d.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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. Typically, my wifi reaches only 10% of that throughput. Additionally, encryption is usually done by the network adapter in hardware, as far as I know. The host CPU shouldn't be stressed by that. Thanks. What's the CPU usage like while doing AES on 20Mb? 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. J. -- At night I go to the kitchen; specifically, the knife drawer. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Let's talk about HTTPS Everywhere
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 Or, of course, disable JavaScript (go, NoScript!). Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123150630.4aecc0e6.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 public) unencrypted. If traffic is unencrypted, it is trivial for anyone to capture session IDs flying in plain text through the air. If the network is encrypted, then it is much harder to capture other people's traffic. (Should be impossible, but there are attacks. But things are much more difficult.) I agree. Wired networks are not that exposed to these attacks. Not entirely true. On a hubbed network, putting your network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. I know very little about enterprise networking, but are hubs still in actual use today? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123232120.5a8f8565.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 up, and to quantify the performance hit? I've never noticed one, but I've not actually benchmarked. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123232306.cffeb07b.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 the client. Do you have a concrete proposal that is simpler than using HTTPS? 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. Cookies are insecure by their own nature and fail to provide a proven mechanism for uniquely identifying users. You can hide (by encrypting the file) the content of the cookie and you'll avoid remote side hijacking when someone is sniffing the connection, but the root of problem still remains: should the hijacker has physical access to the computer I guess he can also impersonate the login session (someone in the know may want to correct this statement). 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 and keeps the full session encrypted via https (not just the login part). Another user with access to the flash drive could copy the whole content of the data and re- use (hijack) the cookie that holds the session id. What I was trying to expose here is that http is a protocol designed mostly for single-user sessions in mind and todays online services are powerful enough to require enhanced security measures that current http protocol specs are not always ready to provide. With cookies, we're applying patches/bypasses but not a definite solution to the problem. The same happened with e-mail: e-mail servers are not well-suited for handling 1 GiB of data attachments (neither Gmail provides such option, attachments are limited to 20-30 MiB) because of e-mail's own definition and we have to use alternative methods (ftp, direct links to online storage sites...) for this. Maybe is just we are not using the right tool for the job... Keep in mind that IPs don't identify users -- proxies and reverse proxies mess that up. Keep in mind that it is difficult to serialize requests; users that are fans of multiple tabs and/or windows may have requests that overlap or interleave with other requests. What can be done now? Of course, always use encryption when dealing with sensitive data and if we are using cookies to store this data (like session ID) apply additional steps that require a second verification of the user and not just trust in the session ID. For instance, once the user has been logged in and the cookie has been set, add a mark -kinda counter/timestamp flag- on the server side that enforces the user to relogin when different session is requested/ detected, from another IP/another browser/etc... Yes, this can be annoying if the request is valid but I prefer a bit of annoyance than getting my account stolen. mode fake-guru on I think in a near future, cloud services will require the use of small VPNs between the provider and user to ensure a correct management of the user's data, security and encryption so private and public information will be kept under two complete separate scenarios. /mode fake-guru off Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.15.39...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 security measures for verifying the authenticity of the client. Do you have a concrete proposal that is simpler than using HTTPS? 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. Cookies are insecure by their own nature and fail to provide a proven mechanism for uniquely identifying users. You can hide (by encrypting the file) the content of the cookie and you'll avoid remote side hijacking when someone is sniffing the connection, but the root of problem still remains: should the hijacker has physical access to the computer I guess he can also impersonate the login session (someone in the know may want to correct this statement). 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 and keeps the full session encrypted via https (not just the login part). Another user with access to the flash drive could copy the whole content of the data and re- use (hijack) the cookie that holds the session id. Cookies that allow the user to bypass a security measure are often aggressively timed out and/or cleared server-side, preventing this from happening in practice unless the first user authorizes it. 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. What I was trying to expose here is that http is a protocol designed mostly for single-user sessions in mind and todays online services are powerful enough to require enhanced security measures that current http protocol specs are not always ready to provide. With cookies, we're applying patches/bypasses but not a definite solution to the problem. Does a session need to last longer than a TCP/IP connection? If so, the sides would have to exchange session identifiers in a way that is quite similar to using cookies. For details look how SSL/TLS allows reusing an existing session on a new TCP/IP connection. There might be a better solution, but it would look very similar to cookie use under a well-considered cookie policy. Maybe is just we are not using the right tool for the job... If a session only needs to last for the length of a TCP/IP connection, then we are almost certainly using the wrong approach, but we'd likely still want HTTP cookies for storing non-sensitive data over long periods of time. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Let's talk about HTTPS Everywhere
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 the remember me option and keeps the full session encrypted via https (not just the login part). Another user with access to the flash drive could copy the whole content of the data and re- use (hijack) the cookie that holds the session id. Cookies that allow the user to bypass a security measure are often aggressively timed out and/or cleared server-side, preventing this from happening in practice unless the first user authorizes it. 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 hardware but data. We only need the data to get the encrypted cookie and hijack the login session. That's a bit different than having access to a computer and be able to change the root's password. As per kerberos, I have not read any case of session hijacking, I thought it was a very sctrict (with high requirements) protocol :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.16.44...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 online account (facebook, gmail, whatever...), check the remember me option and keeps the full session encrypted via https (not just the login part). Another user with access to the flash drive could copy the whole content of the data and re- use (hijack) the cookie that holds the session id. Cookies that allow the user to bypass a security measure are often aggressively timed out and/or cleared server-side, preventing this from happening in practice unless the first user authorizes it. 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 hardware but data. Please provide a scenario where they have access to the data, but not the hardware. Your example quoted above assumed they have access to the removable flash drive, which is hardware. We only need the data to get the encrypted cookie and hijack the login session. That's a bit different than having access to a computer and be able to change the root's password. As per kerberos, I have not read any case of session hijacking, I thought it was a very sctrict (with high requirements) protocol :-? It is. Still, if you store your tickets (Kerberos term) on a flash drive, I have an approximately 5 minute window to steal the drive and authenticate to those services. (I think client and/or server can use a smaller window, but I'm not entirely sure.) NB: Both Kerberos and most web sites / applications are some way to log out / off which invalidates your cookie / ticket. Use of this feature likely prevents many of the attacks. It is even more dangerous if you store your (Kerberos) TGT there, since it can be used to authenticate against arbitrary services. After 5 minutes, the tickets are no longer valid. Tickets are very much like cookies that record an encrypted session id. They are created as part of successful authentication, but don't contain any sensitive information, and are exchanged in lieu of re-authenticating within the same session. NB: It's been a while since I dealt with Kerberos. Tickets may normally be written to disk encrypted; I know cookies are generally not. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Let's talk about HTTPS Everywhere
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, some do), but rather that even just a session ID - which can be just a random number with no meaning other than identifying in the server data related to that user, even if has nothing sensitive, can be used to hijack the session if another uses gets hold of that ID, depending on how the server side is implemented. Several sites fall to this attack (as FireSheep shows). I confess I don't have a good solution on how to solve that in the server side. If traffic is unencrypted (http), then it's easy to capture session IDs. SSL prevents that, even if someone can sniff the traffic, all they get is random garbage. (At least in theory, but I don't know of any real attack on SSL.) 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 through the air. If the network is encrypted, then it is much harder to capture other people's traffic. (Should be impossible, but there are attacks. But things are much more difficult.) Cookies are insecure by their own nature and fail to provide a proven mechanism for uniquely identifying users. You can hide (by encrypting the file) the content of the cookie and you'll avoid remote side hijacking when someone is sniffing the connection, but the root of problem still remains: should the hijacker has physical access to the computer I guess he can also impersonate the login session (someone in the know may want to correct this statement). 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 and keeps the full session encrypted via https (not just the login part). Another user with access to the flash drive could copy the whole content of the data and re- use (hijack) the cookie that holds the session id. Well, if someone has physical access to the hardware, it's game over. They can do everything with it. Encrypting the contents of the HD can limit somewhat what someone can do, though. What I was trying to expose here is that http is a protocol designed mostly for single-user sessions [...] Maybe is just we are not using the right tool for the job... I'd agree, but I don't see things changing any time soon. Just see the status of IPv6 transition: IPv4 addresses are running out, and yet very few people are bothering to switch for IPv6. The same will happen: even if a new protocol is proposed, browsers won't rush to support it because no sites will be using it, and no sites will use it because few browsers support the new protocol. -- 1 + 1 = 3, for large values of 1. Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3b145e.2090...@kalinowski.com.br
Re: Let's talk about HTTPS Everywhere
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 insecure. (...) Not hardware but data. Please provide a scenario where they have access to the data, but not the hardware. Your example quoted above assumed they have access to the removable flash drive, which is hardware. (...) I meant, the hardware itself is irrelevant for the case. It can be on a flash stick, on external drive, on a notebook or even stored online. Once you get the source (the encrypted cookie with the session id) the server does not make further validations. You don't know what is the content of the session id but you can use it anyway. I dunno how easily by-passable is a kerberos based security. You say it is (or it can be) and I have to trust you as I have no experience with this auth method. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.18.22...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 problem. The problem is not that cookies contain sensitive data (well, some do), but rather that even just a session ID - which can be just a random number with no meaning other than identifying in the server data related to that user, even if has nothing sensitive, can be used to hijack the session if another uses gets hold of that ID, depending on how the server side is implemented. Several sites fall to this attack (as FireSheep shows). I confess I don't have a good solution on how to solve that in the server side. Well, I think the problem is that online services rely just on cookies (whether encrypted or not) and do not apply additional verification steps to check if the user is the one who claims to be. And that's a bad proceeding, IMO. If traffic is unencrypted (http), then it's easy to capture session IDs. SSL prevents that, even if someone can sniff the traffic, all they get is random garbage. (At least in theory, but I don't know of any real attack on SSL.) Yes, but there are also cross-site scripting attacks that are not mitigated by using ssl but implementing another methodologies (wikipedia talks about HttpOnly flag to use within the http response header but this is still a draft, if I read it correctly. 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 through the air. If the network is encrypted, then it is much harder to capture other people's traffic. (Should be impossible, but there are attacks. But things are much more difficult.) I agree. Wired networks are not that exposed to these attacks. Cookies are insecure by their own nature and fail to provide a proven mechanism for uniquely identifying users. You can hide (by encrypting the file) the content of the cookie and you'll avoid remote side hijacking when someone is sniffing the connection, but the root of problem still remains: should the hijacker has physical access to the computer I guess he can also impersonate the login session (someone in the know may want to correct this statement). 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 and keeps the full session encrypted via https (not just the login part). Another user with access to the flash drive could copy the whole content of the data and re- use (hijack) the cookie that holds the session id. Well, if someone has physical access to the hardware, it's game over. They can do everything with it. Encrypting the contents of the HD can limit somewhat what someone can do, though. Having access to removable media is very easy (they're tend to be left unattended, mostly at the office) and a high percentage of the people do not encrypt the data on it neither by software nor hardware. That's why I choose the flash drive to illustrate the above example. What I was trying to expose here is that http is a protocol designed mostly for single-user sessions [...] Maybe is just we are not using the right tool for the job... I'd agree, but I don't see things changing any time soon. Just see the status of IPv6 transition: IPv4 addresses are running out, and yet very few people are bothering to switch for IPv6. The same will happen: even if a new protocol is proposed, browsers won't rush to support it because no sites will be using it, and no sites will use it because few browsers support the new protocol. Yes, and switching to ipv6 should be *a must*, not a *recommended* option. After all, this discussion was generated because people wanted to use ssl all the time for all the tasks and I did not agree on that :-) And I still fail to see why should we encrypt _all_ of our browsing steps regardless its nature. It reminds me the same argument that people uses to convince others to switch into imap instead pop. I can accept that imap provides some advantages, but pop still has it uses. I'm open to changes but with a good and logical reasoning inside. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.18.58...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 Kerberos network; that's not generally considered insecure. Not hardware but data. Please provide a scenario where they have access to the data, but not the hardware. Your example quoted above assumed they have access to the removable flash drive, which is hardware. I meant, the hardware itself is irrelevant for the case. It can be on a flash stick, on external drive, on a notebook or even stored online. Once you get the source (the encrypted cookie with the session id) the server does not make further validations. You don't know what is the content of the session id but you can use it anyway. As long as the timeout is relatively small (e.g. 5 minutes) this is generally considered secure. HTTPS Everywhere prevents cookies from being intercepted on-the-wire, which prevents sidejacking attacks. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Let's talk about HTTPS Everywhere
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 IDs flying in plain text through the air. If the network is encrypted, then it is much harder to capture other people's traffic. (Should be impossible, but there are attacks. But things are much more difficult.) I agree. Wired networks are not that exposed to these attacks. Not entirely true. On a hubbed network, putting your network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. WPA2 is still relatively secure. WEP and WPA have known attacks that allow attackers in radio range to effectively tap to connection between the client and the AP, in addition to joining the AP as a client. And I still fail to see why should we encrypt _all_ of our browsing steps regardless its nature. Not encrypting is fine, if you are willing to expose the entirety of the connection to tapping at various locations. Most notably all the switches between you and the destination. However, session cookies (and other authentication tokens) are not generally something you want disclosed with is why end-to-end encryption with some sort of server authentication is recommended for transferring that data. At the end of the day, a server must use *something* in the request itself to associate it with a user. That something must be protected from snooping, so end-to-end encryption is required. Encrypted session cookies are more secure that any of the HTTP Auth mechanisms for use after the initial log in / on. For the initial log in / on, we are already accustomed to using SSL/TLS since it is more widely supported that any of the secure HTTP Auth mechanisms. HTTP Everywhere is meant as a way for users to protect themselves when the servers refuse to for whatever reason. Ideally, servers would take only non- sensitive actions and provide only non-sensitive information over HTTP (and of course, automatically downgrade cookies transferred over HTTP to only for non-sensitive status), but some server don't actually see that as being in their interest. (E.g. Facebook loses relatively few page views if it discloses too much information about you.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Let's talk about HTTPS Everywhere
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 traffic is unencrypted, it is trivial for anyone to capture session IDs flying in plain text through the air. If the network is encrypted, then it is much harder to capture other people's traffic. (Should be impossible, but there are attacks. But things are much more difficult.) I agree. Wired networks are not that exposed to these attacks. Not entirely true. On a hubbed network, putting your network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. A wired network can be easily monitored while wireless ones need additional effort. You control the cables so you can control the traffic and possible black points. A misconfigured wifi access point or a buggy firmware in the device can lead to open access to anywhere inside the AP range. WPA2 is still relatively secure. WEP and WPA have known attacks that allow attackers in radio range to effectively tap to connection between the client and the AP, in addition to joining the AP as a client. And WPA2 with AES encryption is considerably slow. There are also drawbacks when you enforce to use of the best encryption method. And I still fail to see why should we encrypt _all_ of our browsing steps regardless its nature. Not encrypting is fine, if you are willing to expose the entirety of the connection to tapping at various locations. Most notably all the switches between you and the destination. However, session cookies (and other authentication tokens) are not generally something you want disclosed with is why end-to-end encryption with some sort of server authentication is recommended for transferring that data. I would prefer to see a good cookie policy that should be enforced to companies. If you want to keep a secret do not write it anywhere. At the end of the day, a server must use *something* in the request itself to associate it with a user. That something must be protected from snooping, so end-to-end encryption is required. Encrypted session cookies are more secure that any of the HTTP Auth mechanisms for use after the initial log in / on. For the initial log in / on, we are already accustomed to using SSL/TLS since it is more widely supported that any of the secure HTTP Auth mechanisms. You need more than encrypted traffic to avoid some of those hijacking attacks. Https helps, sure, but it's not the panacea and the cure for all the treats. It should be used in conjunction with additional measures. HTTP Everywhere is meant as a way for users to protect themselves when the servers refuse to for whatever reason. If the server refuses to provide https the plugin can't do much. Ideally, servers would take only non- sensitive actions and provide only non-sensitive information over HTTP (and of course, automatically downgrade cookies transferred over HTTP to only for non-sensitive status), but some server don't actually see that as being in their interest. (E.g. Facebook loses relatively few page views if it discloses too much information about you.) And precisely Facebook is a perfect example of bad policy (they have a long record of privacy issues, most of them involving coding bugs and relaxed privacy rules). Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.21.00...@gmail.com
Re: Let's talk about HTTPS Everywhere
Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. http://hakipedia.com/index.php/CAM_Table_Overflow#Description --- On Sat, 1/22/11, Camaleón noela...@gmail.com wrote: From: Camaleón noela...@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 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 through the air. If the network is encrypted, then it is much harder to capture other people's traffic. (Should be impossible, but there are attacks. But things are much more difficult.) I agree. Wired networks are not that exposed to these attacks. Not entirely true. On a hubbed network, putting your network card into promiscuous mode will allow you do see other's HTTP traffic and sidejack them. Even on a switched network, there may be a way to fool the switch into giving you enough data from the HTTP traffic to preform a sidejack. A wired network can be easily monitored while wireless ones need additional effort. You control the cables so you can control the traffic and possible black points. A misconfigured wifi access point or a buggy firmware in the device can lead to open access to anywhere inside the AP range. WPA2 is still relatively secure. WEP and WPA have known attacks that allow attackers in radio range to effectively tap to connection between the client and the AP, in addition to joining the AP as a client. And WPA2 with AES encryption is considerably slow. There are also drawbacks when you enforce to use of the best encryption method. And I still fail to see why should we encrypt _all_ of our browsing steps regardless its nature. Not encrypting is fine, if you are willing to expose the entirety of the connection to tapping at various locations. Most notably all the switches between you and the destination. However, session cookies (and other authentication tokens) are not generally something you want disclosed with is why end-to-end encryption with some sort of server authentication is recommended for transferring that data. I would prefer to see a good cookie policy that should be enforced to companies. If you want to keep a secret do not write it anywhere. At the end of the day, a server must use *something* in the request itself to associate it with a user. That something must be protected from snooping, so end-to-end encryption is required. Encrypted session cookies are more secure that any of the HTTP Auth mechanisms for use after the initial log in / on. For the initial log in / on, we are already accustomed to using SSL/TLS since it is more widely supported that any of the secure HTTP Auth mechanisms. You need more than encrypted traffic to avoid some of those hijacking attacks. Https helps, sure, but it's not the panacea and the cure for all the treats. It should be used in conjunction with additional measures. HTTP Everywhere is meant as a way for users to protect themselves when the servers refuse to for whatever reason. If the server refuses to provide https the plugin can't do much. Ideally, servers would take only non- sensitive actions and provide only non-sensitive information over HTTP (and of course, automatically downgrade cookies transferred over HTTP to only for non-sensitive status), but some server don't actually see that as being in their interest. (E.g. Facebook loses relatively few page views if it discloses too much information about you.) And precisely Facebook is a perfect example of bad policy (they have a long record of privacy issues, most of them involving coding bugs and relaxed privacy rules). Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.21.00...@gmail.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/97048.73019...@web121403.mail.ne1.yahoo.com
Re: Let's talk about HTTPS Everywhere
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 exist within a single base URI, yes, we do need to *constantly* read cookies. That's the way browsers work - if the browser holds any cookies related to a given URI, it will send those cookies on *every* request to that URI. The cookies are not requested on a per-fetch basis by the server. The only way around this is to have separate /public and /authenticated spaces within your app's URI space and set all cookies to apply only to the /authenticated space. This isn't a viable solution these days, however, as it means that documents in the /public space will have absolutely no access to any information regarding the user or his session, so it won't be able to do things that users have become accustomed to, such as showing who you're logged in as (or even whether you're logged in at all, making any login or logout links within the /public space problematic, at best). (Well, OK, there is one other way around it: Discard the stateless HTTP protocol and replace it with a protocol based on persistent connections so that you don't have to fake persistence by using cookies to re-identify yourself every time you talk to the server, but there's no way that's happening any time soon.) If the data, that now is being exchanged between the server and user's computer by means of cookies, is to be stored in the server itself in a database, most of theses attacks could be prevented. Any decent site will only use a single cookie containing a random session ID and store all additional data on the server itself, keyed to that ID. In this (extremely common) scenario, the only thing being exchanged between the server and the user's computer by means of cookies is this identification token; storing it solely on the server and not repeatedly exchanging it would mean that the server is not able to identify the user. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110121092126.gh3...@sherohman.org
Re: Let's talk about HTTPS Everywhere
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 *all* the tasks?. On these days, no one of us can browse the web and join to online services with a completely cookie disabled browser and that's a bit excessive, IMO. If the data, that now is being exchanged between the server and user's computer by means of cookies, is to be stored in the server itself in a database, most of theses attacks could be prevented. How? However your browser is identifying itself to the server, if encryption isn't in use, that token can be hijacked. Well, I already said that the login screen is a key point (where the user provides sensible data) and as such has to use a secure channel and enforce data encryption but not the remainder traffic. So the problem here is about identifying the unneeded and avoidable information exchange that flows between the server and the client. 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. Sensible data needs, at least, a secure/encrypted channel... is the user's session ID considered sensible, okay, then use it but do not abuse of it! In addition, enforcing a good policy, like user login session regeneration or logouts, also help but these options are not always neither implemented nor enforced and most of the new cloud services rely on full-session encryption to simplify things. Again, I'd certainly want full-session ideally, to avoid MITM and similar threats. I can see that many of the new cloud services need to use encryption to protect their users but not all the sections of the sites require the same level of confidentiality, neither all the actions do, i.e., do you need to use a secure channel when performing a google search, browsing digg, reading slashdot or even posting to this mailing list? What I mean is that enforcing a 100% https policy without a notion of what we want to prevent would be like telling people that whenever they are going shopping and use their plastic credit card, tell the seller please, do not look at it to avoid him getting the numbers :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.21.12.44...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 for *all* the tasks?. Unfortunately, if the site is to exist within a single base URI, yes, we do need to *constantly* read cookies. That's the way browsers work - if the browser holds any cookies related to a given URI, it will send those cookies on *every* request to that URI. The cookies are not requested on a per-fetch basis by the server. But not for all the tasks! This cookie policy is being enforced by companies, but it is not a programming requirement. 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 Why Google prefers using cookies is something we all here should guess: tracking the users. Is it licit...? Yes, but in the end, this is not a technical based policy (we do this way because we cannot do it in another way), it's a marketing policy. (...) (Well, OK, there is one other way around it: Discard the stateless HTTP protocol and replace it with a protocol based on persistent connections so that you don't have to fake persistence by using cookies to re-identify yourself every time you talk to the server, but there's no way that's happening any time soon.) Which reminds me the current state of the old smtp protocol. Instead of getting a complete redesign of it (it is broken by design) we are still looking for bypasses (like SPF, domainkeys or dkim implementations...) to avoid spam, prevent user usurpation and keeping message integrity. If the data, that now is being exchanged between the server and user's computer by means of cookies, is to be stored in the server itself in a database, most of theses attacks could be prevented. Any decent site will only use a single cookie containing a random session ID and store all additional data on the server itself, keyed to that ID. In this (extremely common) scenario, the only thing being exchanged between the server and the user's computer by means of cookies is this identification token; storing it solely on the server and not repeatedly exchanging it would mean that the server is not able to identify the user. Then encrypt it at login and apply additional measures to prevent it can be hijacked, but you need to be aware that just by using ssl you are not completely safe against all kind of attacks. Look: *** http://en.wikipedia.org/wiki/HTTP_cookie#Drawbacks_of_cookies ... A different way to steal cookies is cross-site scripting and making the browser itself send cookies to malicious servers that should not receive them. Modern browsers allow execution of pieces of code retrieved from the server. If cookies are accessible during execution, their value may be communicated in some form to servers that should not access them. Encrypting cookies before sending them on the network does not help against this attack.[37] *** Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.21.13.20...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 using HTTPS? Keep in mind that IPs don't identify users -- proxies and reverse proxies mess that up. Keep in mind that it is difficult to serialize requests; users that are fans of multiple tabs and/or windows may have requests that overlap or interleave with other requests. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Let's talk about HTTPS Everywhere
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 who gains access to that data would be able to use those cookies to impersonate you for the lifetime of that session, as demonstrated by the recent uproar over FireSheep. Data stored in cookies is not what I understand for sensitive. What kind of information do you think are cookies managing? As I said earlier, websites which use persistent sessions store the session id in a cookie. While this cookie does not contain any data which is meaningful outside of the context of your persistent session, it is somewhat sensitive in that an attacker would be able to impersonate you by cloning your session cookie. This would then allow them to create or access content on the site which issued the cookie as if they were you, potentially gaining access to more conventionally sensitive information or fraudulently posting from your accout, for the remaining lifetime of the session. 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 multiple users to appear on a single address) or reverse proxies (which can cause a single user to appear on multiple addresses), so https really is the only surefire way to prevent it. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120093603.gg3...@sherohman.org
Re: Let's talk about HTTPS Everywhere
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 website you are logged in. Say you log into your friendface account, and someone near your catch your unencrypted session cookie, then he is YOU on YOUR friendface account... That sounds like bad programming or a buggy site. There are methods to prevent such attacks on the server side that involves no encrypted sessions, but sometimes it is easier (and cheaper) for companies to rely on completely encrypted sessions and not implement another countermeasures. I'm curious - how can one completely guard against a MITM attack without using encryption? We were talking about session hijacking which is a bit different from man in the middle attacks. In fact, this kind of threat (man in the middle) cannot even be totally prevented with just https (the Sans Institute published a good article on the matter¹ -as well as another interesting papers that can be found here²) so when it comes to security, relying in only one point of failure should be avoided at all. 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?. On these days, no one of us can browse the web and join to online services with a completely cookie disabled browser and that's a bit excessive, IMO. If the data, that now is being exchanged between the server and user's computer by means of cookies, is to be stored in the server itself in a database, most of theses attacks could be prevented. In addition, enforcing a good policy, like user login session regeneration or logouts, also help but these options are not always neither implemented nor enforced and most of the new cloud services rely on full-session encryption to simplify things. ¹http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480 ²http://www.sans.org/reading_room/whitepapers/threats/ Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.20.15.26...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 include the cookie(s) which identify you and an attacker who gains access to that data would be able to use those cookies to impersonate you for the lifetime of that session, as demonstrated by the recent uproar over FireSheep. Data stored in cookies is not what I understand for sensitive. What kind of information do you think are cookies managing? As I said earlier, websites which use persistent sessions store the session id in a cookie. While this cookie does not contain any data which is meaningful outside of the context of your persistent session, it is somewhat sensitive in that an attacker would be able to impersonate you by cloning your session cookie. This would then allow them to create or access content on the site which issued the cookie as if they were you, potentially gaining access to more conventionally sensitive information or fraudulently posting from your accout, for the remaining lifetime of the session. 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 multiple users to appear on a single address) or reverse proxies (which can cause a single user to appear on multiple addresses), so https really is the only surefire way to prevent it. (as I just have mentioned to Celejar, these problems do exist but they're not exclusively solved with https encryption) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.20.15.34...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 (which can cause multiple users to appear on a single address) or reverse proxies (which can cause a single user to appear on multiple addresses), so https really is the only surefire way to prevent it. And it also won't help against an attacker who can use your IP address, such as a MITM attacker from the local network segment. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120101155.01ce1804.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 widespread and, even when it is employed, it has issues with proxies (which can cause multiple users to appear on a single address) or reverse proxies (which can cause a single user to appear on multiple addresses), so https really is the only surefire way to prevent it. And it also won't help against an attacker who can use your IP address, such as a MITM attacker from the local network segment. Unless you give them a cert and then proxy their connection... you're not really breaking ssl there though. The handshake and encryption is still sound.
Re: Let's talk about HTTPS Everywhere
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 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 your friendface account, and someone near your catch your unencrypted session cookie, then he is YOU on YOUR friendface account... That sounds like bad programming or a buggy site. There are methods to prevent such attacks on the server side that involves no encrypted sessions, but sometimes it is easier (and cheaper) for companies to rely on completely encrypted sessions and not implement another countermeasures. I'm curious - how can one completely guard against a MITM attack without using encryption? We were talking about session hijacking which is a bit different from man in the middle attacks. In fact, this kind of threat (man in the middle) cannot even be totally prevented with just https (the Sans Institute published a good article on the matter¹ -as well as another interesting papers that can be found here²) so when it comes to security, relying in only one point of failure should be avoided at all. Interesting, thanks. But the service provider should still be doing SSL to avoid MITM attacks (AFAICT from the SANS paper's abstract, the problems with SSL have to do with faulty implementations, and can be avoided / mitigated with proper ones, and user care). 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?. On these days, no one of us can browse the web and join to online services with a completely cookie disabled browser and that's a bit excessive, IMO. If the data, that now is being exchanged between the server and user's computer by means of cookies, is to be stored in the server itself in a database, most of theses attacks could be prevented. How? However your browser is identifying itself to the server, if encryption isn't in use, that token can be hijacked. In addition, enforcing a good policy, like user login session regeneration or logouts, also help but these options are not always neither implemented nor enforced and most of the new cloud services rely on full-session encryption to simplify things. Again, I'd certainly want full-session ideally, to avoid MITM and similar threats. ¹http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480 ²http://www.sans.org/reading_room/whitepapers/threats/ Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120165752.cd040997.cele...@gmail.com
Let's talk about HTTPS Everywhere
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? 4) If it's so great why isn't it more prevalent? What's youre opinion? Or answer? :\ Thanks! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518009.96732...@web121410.mail.ne1.yahoo.com
Re: Let's talk about HTTPS Everywhere
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 to worry about, since this is en EFF project. 4) If it's so great why isn't it more prevalent? I think you're a bit confused about what this extension does. It doesn't magically secure connections to all websites, it merely instructs the browser to use the https protocol with websites that support it but don't have it enabled by default. Remember that https, compared with http, requires some extra work on both the client and the server. Therefore, websites are reluctant to enable it by default, unless it is absolutely necessary. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTik=nyqpnBKokhG5eQficyhXKF=u5rzj+1bqj...@mail.gmail.com
Re: Let's talk about HTTPS Everywhere
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://chrome.google.com/extensions/detail/flcpelgcagfhfoegekianiofphddckof?hl=en -- Paul Cartwright Registered Linux user # 367800 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d36dd6c.7080...@pcartwright.com
Re: Let's talk about HTTPS Everywhere
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.googleusercontent.com/search?q=cache:udWjQhqxiWoJ:https://addons.mozilla.org/es-ES/firefox/addon/229918/+HTTPS+Everywherecd=3hl=esct=clnkclient=iceweasel-a 2) Did anyone audited the HTTPS Everywhere code? This dunno... 3) Can someone trust this Add-on? Is it safe to install/use? I don't like/trust anoymous (even encrypted) proxy sites. 4) If it's so great why isn't it more prevalent? - SSL traffic is heavy and slow - There no need (normally) for encrypting public navigation (see the note below) What's youre opinion? Or answer? :\ My opinion is that I don't want to encrypt all the traffic, at least not with the slow DSL connections/hosts we have now (loading a single page will take seconds). I prefer to leave the SSL/TLS for sensitive data (logins, etc...). Or better yet, provide a hardware solution for transparently encrypt all the data and its transport. Software is slow :-) (note) I can see it could be useful for countries with non-free goverments, or for another, hum, uses... Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.19.12.57...@gmail.com
Re: Let's talk about HTTPS Everywhere
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, or otherwise. It causes your browser to request that the sites you visit use HTTPS rather than cleartext HTTP when communicating (directly) with you. Nothing more, nothing less. 4) If it's so great why isn't it more prevalent? - SSL traffic is heavy and slow ... My opinion is that I don't want to encrypt all the traffic, at least not with the slow DSL connections/hosts we have now (loading a single page will take seconds). I don't know where you get this idea. SSL traffic is no different on the wire than any other data traffic. There is a cost in processing overhead for running the encryption algorithms on the client and on the server, but it does not incur any additional bandwidth requirements and, with modern hardware, the additional processing cost is negligible. - There no need (normally) for encrypting public navigation (see the note below) ... I prefer to leave the SSL/TLS for sensitive data (logins, etc...). 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 who gains access to that data would be able to use those cookies to impersonate you for the lifetime of that session, as demonstrated by the recent uproar over FireSheep. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110119131758.gf3...@sherohman.org
Re: Let's talk about HTTPS Everywhere
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 what does that have to do with https everywhere? 4) If it's so great why isn't it more prevalent? - SSL traffic is heavy and slow - There no need (normally) for encrypting public navigation (see the note below) What's youre opinion? Or answer? :\ My opinion is that I don't want to encrypt all the traffic, at least not with the slow DSL connections/hosts we have now (loading a single page will take seconds). I prefer to leave the SSL/TLS for sensitive data (logins, etc...). SSL/TLS isn't going to add enough overhead to the packets to make a real difference unless you are something slower than DSL. As far as the encryption/decryption goes, unless you are on a smartphone or netbook or a really old computer, it will not matter to you. If enough people do it, it will matter to the servers, but that is what capacity planning and NICs with encryption offloading engines are for. Or better yet, provide a hardware solution for transparently encrypt all the data and its transport. Software is slow :-) See NICs with encryption offloading engines above. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi�9jdSNihgbXC=syykrbojs9bk5po9qjok...@mail.gmail.com
Re: Let's talk about HTTPS Everywhere
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. HTTPS Everywhere is not a proxy site, encrypted, anonymous, or otherwise. It causes your browser to request that the sites you visit use HTTPS rather than cleartext HTTP when communicating (directly) with you. Nothing more, nothing less. Maybe I read it wrong. In the EFF page says the addon has been developed by Tor (I guess you already know what is this) and the EFF. 4) If it's so great why isn't it more prevalent? - SSL traffic is heavy and slow ... My opinion is that I don't want to encrypt all the traffic, at least not with the slow DSL connections/hosts we have now (loading a single page will take seconds). I don't know where you get this idea. SSL traffic is no different on the wire than any other data traffic. There is a cost in processing overhead for running the encryption algorithms on the client and on the server, but it does not incur any additional bandwidth requirements and, with modern hardware, the additional processing cost is negligible. And that cost translates into slow page loading that is even worse if your connection is not as good as it should. - There no need (normally) for encrypting public navigation (see the note below) ... I prefer to leave the SSL/TLS for sensitive data (logins, etc...). 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 who gains access to that data would be able to use those cookies to impersonate you for the lifetime of that session, as demonstrated by the recent uproar over FireSheep. Data stored in cookies is not what I understand for sensitive. What kind of information do you think are cookies managing? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.19.14.47...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 you like them (I get not trusting them), and what does that have to do with https everywhere? As I already said, I thought Tor (a multi-proxy and encrypted network) was somehow being used with this addon. What's youre opinion? Or answer? :\ My opinion is that I don't want to encrypt all the traffic, at least not with the slow DSL connections/hosts we have now (loading a single page will take seconds). I prefer to leave the SSL/TLS for sensitive data (logins, etc...). SSL/TLS isn't going to add enough overhead to the packets to make a real difference unless you are something slower than DSL. As far as the encryption/decryption goes, unless you are on a smartphone or netbook or a really old computer, it will not matter to you. If enough people do it, it will matter to the servers, but that is what capacity planning and NICs with encryption offloading engines are for. I tried many times to use Google services via https (the search engine and Gmail's webmail) but finally left it because I experience a bit of delay when running all the javascript and their dynamic stuff. This is just an example, I know, but encrypted sites has to be very well configured to avoid noticeable delays. Or better yet, provide a hardware solution for transparently encrypt all the data and its transport. Software is slow :-) See NICs with encryption offloading engines above. That's interesing, I have read more on this. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.19.15.02...@gmail.com
Re: Let's talk about HTTPS Everywhere
-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: http://codebutler.com/firesheep FTA: It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called sidejacking) is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy. - -- Those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTTcJDi9Y35yItIgBAQJmvgf/aKGqgKI6mex6ncwMBbSCKhWzqQAw99Dm K46w011tD1CGKz7p7NYhcODukChXsKp168SRGAGkD9YVGYvzFRk5r/YnMhNxEe0B wfNu+Y51BXlHz1kUwPDcJ5iri4GDhvD2A8ZJ1LQy4O35nKSsdgVsJWkSkQezIumm VYX1M/LKoexvNU7XdZZhyqbh8QEC2rDVkKXBAqI/TxpLoYGsl/LL1gxKe/Ee/DFQ t7KiSXhEICmowEaDvc9Cbx/DjwYBrNW0U00FgY8M9TMDcc1I6627lXNWuoYwTvIb rE1iKhHs2c37USgiNvasOYcy+ouYqvjT/yiK7KA+S73DLBEgMoX85w== =2GLc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101191053.50768.howl...@priss.com
Re: Let's talk about HTTPS Everywhere
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://codebutler.com/firesheep FTA: It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called sidejacking) is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy. Maybe I have not expressed myself properly. Any data passing through an unencrypted channel is vulnerable to be fetched and reviewed by anyone and we all know that. My point here is that I don't mind about _that kind of data_ to be disclosed because is public and easily gathered by other means (anyone reading my e-mail headers can see my IP address and/or e-mail client) and tracking cookies (session cookies) do not contain sensible information (by sensible information I mean passwords or username logins for gaining access to online services, like banking, shopping or such). In brief: - Does the cookie contain sensitive/private information? → set/get the cookie using ssl - Does the cookie contain standard/publicly available information → no need to be encrypted What I fear, most than unencrypted browsing, is e-mail/ftp logins using clear text passwords. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.19.16.46...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 would be enlightening: http://codebutler.com/firesheep FTA: It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called sidejacking) is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy. Maybe I have not expressed myself properly. Any data passing through an unencrypted channel is vulnerable to be fetched and reviewed by anyone and we all know that. My point here is that I don't mind about _that kind of data_ to be disclosed because is public and easily gathered by other means (anyone reading my e-mail headers can see my IP address and/or e-mail client) and tracking cookies (session cookies) do not contain sensible information (by sensible information I mean passwords or username logins for gaining access to online services, like banking, shopping or such). In brief: - Does the cookie contain sensitive/private information? → set/get the cookie using ssl - Does the cookie contain standard/publicly available information → no need to be encrypted What I fear, most than unencrypted browsing, is e-mail/ftp logins using clear text passwords. Greetings, 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 your friendface account, and someone near your catch your unencrypted session cookie, then he is YOU on YOUR friendface account... Enjoy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d371a58.9060...@googlemail.com
Re: Let's talk about HTTPS Everywhere
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 contain standard/publicly available information → no need to be encrypted generally not - the point of a cookie is to retain information about you between the client and the server. here, this should give you some general information. but unless you've worked with this stuff, you're not going to really grasp the full implication of 'name' and 'value' and what not: http://www.cookiecentral.com/faq/#3.3 there's also the wikipedia run down (look at the 'see also' section - it's got some pretty good stuff): http://en.wikipedia.org/wiki/HTTP_cookie if you want to know what can be in a cookie, look at things like httpfox (there's a more popular ff extension that has some of the same features as well that i can't think of too). What I fear, most than unencrypted browsing, is e-mail/ftp logins using clear text passwords. email is not secure. it never was. don't send unencrypted sensitive information over email. than again, if you use a big enough email service (gmail, yahoo, etc) and have nothing to hide from your government (i'm in the us, so here that would include fbi, cia, dhs, dos) i don't think too many people are going to filter through l3 and verizon's data for your message.per ftp, use scp (ftp+ssh, sftp). fact of the matter is, unless you have information that others might profit by, or unless you're popular enough that someone might care enough to defame you, or you don't put yourself out there to be a target, you probably don't have much to worry about. point is, i can walk around my building and capture enough encrypted wifi packets to then go back home, and run aircrack on them all and have fun with everyone (as i'm sure they all surf the web with http and could be exploited in many other ways as well). i don't because, well, why? what would i gain? on the other hand, if i'm hanging around at a library or starbucks with a laptop, i'll pop out wireshark and firesheep just for the hell of it (i'm not often 'hanging around' with nothing better to do). so, fwiw
Re: Let's talk about HTTPS Everywhere
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 need to be encrypted What I fear, most than unencrypted browsing, is e-mail/ftp logins using clear text passwords. 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 your friendface account, and someone near your catch your unencrypted session cookie, then he is YOU on YOUR friendface account... That sounds like bad programming or a buggy site. There are methods to prevent such attacks on the server side that involves no encrypted sessions, but sometimes it is easier (and cheaper) for companies to rely on completely encrypted sessions and not implement another countermeasures. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.19.17.50...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 sessions and not implement another countermeasures. 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. And it's overhead is minimal, to the point that it should not be noticeable unless the computer (client or server) and/or internet connection are very slow. -- Computers are not intelligent. They only think they are. Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011011913.14402bt31wb6f...@mail.kalinowski.com.br
Re: Let's talk about HTTPS Everywhere
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 log into your friendface account, and someone near your catch your unencrypted session cookie, then he is YOU on YOUR friendface account... That sounds like bad programming or a buggy site. There are methods to prevent such attacks on the server side that involves no encrypted sessions, but sometimes it is easier (and cheaper) for companies to rely on completely encrypted sessions and not implement another countermeasures. I'm curious - how can one completely guard against a MITM attack without using encryption? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110119160930.225f5f8b.cele...@gmail.com
Re: Let's talk about HTTPS Everywhere
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 to disclose which is which? And how do you decide that? How do you know what may be interesting for an attacker in the future? From my point if view, opportunistic encryption doesn't cost me anything, but it may help me keep my privacy. J. -- My clothes aren't just fashion. They're a lifestyle. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Let's talk about HTTPS Everywhere
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 was never designed with security as a primary goal. Even today, that is readily apparent.
