RE: phone records for sale.
I got curious about this issue, and did a little digging into what's going on here. It turns out that the FCC is looking into this problem at EPIC's request. EPIC filed a petition for rulemaking on this subject with the FCC - which went out for public comment at the end of the year. The petition itself contains copious material about the practices and methods - which you can download. Use the FCC ECFS template: http://gullfoss2.fcc.gov/prod/ecfs/comsrch_v2.cgi and enter "RM-11277" without the quotes, and click on Retrieve Document List. I found both the original petition and the replies from service providers fascinating. -- Joseph Adler -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry E. Metzger Sent: Friday, January 06, 2006 9:34 AM To: cryptography@metzdowd.com Subject: phone records for sale. The Chicago Sun Times reports that, for the right price, you can buy just about anyone's cell phone records: http://www.suntimes.com/output/news/cst-nws-privacy05.html Quite disturbing. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: phone records for sale.
On Fri, 2006-01-06 at 09:34, Perry E. Metzger wrote: > http://www.suntimes.com/output/news/cst-nws-privacy05.html > > Quite disturbing. More disturbing than even the people at Chicago Sun Times realize apparently. ;) Hope no-one was sniffing their email. 'It was as simple as e-mailing the telephone number to the service along with a credit card number.' - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: phone records for sale.
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes: > >The Chicago Sun Times reports that, for the right price, you can buy >just about anyone's cell phone records: > >http://www.suntimes.com/output/news/cst-nws-privacy05.html > >Quite disturbing. Yes, but it's also bad reporting -- the newspaper neglected to call the cell phone companies and ask what their privacy policies are. What happened may have been 100% legal and explicitly permitted by law... 18 USC 2702(a)(3) says a provider of remote computing service or electronic communication service to the public shall not knowingly divulge a record or other information pertaining to a subscriber to or customer of such service (not including the contents of communications covered by paragraph (1) or (2)) to any governmental entity. 18 USC 2702(c) says A provider described in subsection (a) may divulge a record or other information pertaining to a subscriber to or customer of such service (not including the contents of communications covered by subsection (a)(1) or (a)(2)) ... (6) to any person other than a governmental entity. See http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2702000-.html for the full text. The first time I read that last clause, I couldn't believe it; I actually went and looked up the legislative history. I found that Congress wanted to permit sale for marketing or financial reasons, but wanted to limit the power of the government. (The Supreme Court had ruled previously that individuals had no expectation of privacy for phone numbers they'd dialed, since they were being given voluntarily to a third party -- the phone company.) If the phone companies are not giving it out voluntarily, perhaps they're being tricked or perhaps they have corrupt employees. From my experience, one way you authenticate yourself to a cell phone company is by social security number, and those aren't exactly hard to find. That possibility suggests using stronger authentication, but of course that gets in the way of customer service for the 99.99% of queries that are legitimate. (I've had to call my company from abroad, more than once, on fairly urgent matters. I had no easy access to, say, my last bill.) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
phone records for sale.
The Chicago Sun Times reports that, for the right price, you can buy just about anyone's cell phone records: http://www.suntimes.com/output/news/cst-nws-privacy05.html Quite disturbing. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, Ben Laurie writes: >> Bill Frantz wrote: >>> On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: >>> I don't see why not - the technical details actually matter. Since the servers will all share a socket, on any normal architecture, they'll all have access to everyone's private keys. So, what is gained by having separate certs? >>> I responded in private email: >>> With a POLA architecture, perhaps on a capability OS (dream, dream), they might not share access to the private keys. However, given current software, I grant your point. >>> Ben responded that I should post my comments to the list. >>> >>> There are two scenarios I see as being viable for separating the private >>> keys with a security barrier. One is the single machine case alluded to >>> above. Here the private keys would be in separate security domains, and >>> the common part of the web server, which listens on the socket, would >>> read the initial data on the TCP connection, select the correct security >>> domain, and "pass" the connection to that domain. While the common part >>> could continue to examine all the data, those data would be encrypted, >>> so the it would have the same access as any other untrusted node in the >>> path. >>> >>> The other scenario involves a network switch which performs the function >>> of the common code of the web server. It uses network address >>> translation to forward the connection's packets to the back-end computer >>> with the correct private key. Here the keys are protected by being kept >>> on separate computers. >> This would defeat the reason people share IP addresses, which is so they >> can share a single machine to reduce costs. Of course, a capability OS >> would permit this whilst separating keys, as you said. >> > It doesn't have to be a capability-based OS; one could easily envision > a (ahem) alternate browser strategy accomplish it. Consider, to pick a > non-random example, Apache. Apache 2.0.x (and I think 1.y, but I don't > run it so I can't be sure) forks several child processes to actually > serve the pages. What if the directives contained an > optional User directive that specified the uid each virtual host should > run as? You could have different processes for different virtual hosts. Apache 1.x does indeed service each connection within its own child process. Apache 2.x actually has a more flexible mechanism: it uses things called MPMs (Multi-Processing Modules) which choose how connections are handled. Some of them use threading and some use processes and some use both. There is an MPM called "perchild" which does exactly what you want: http://httpd.apache.org/docs/2.0/mod/perchild.html - sadly, it is not currently functional, though I'm sure that either money or time would make it so. > Yes, that would require more bookkeeping on the part of Apache; it > would also require more (perhaps many more) processes running > simultaneously. I think this is certainly a risk. > Both of those are much smaller changes than a > capability-based OS. (Hmm -- who was it who noted that capability- > based systems were the wave of the future, and always would be?) Someone firmly rooted in the past, perhaps? > A final note -- multiple IP addresses is not the same as multiple > machines. Lots of hosting companies dedicate an IP address to each > customer, but put them all on a single machine. True, but at least with multiple IPs you can bind separate instances of the webserver to each IP on conventional OSes, unlike name-based virtual hosting. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
In message <[EMAIL PROTECTED]>, Ben Laurie writes: >Bill Frantz wrote: >> On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: >> >>> I don't see why not - the technical details actually matter. Since the >>> servers will all share a socket, on any normal architecture, they'll all >>> have access to everyone's private keys. So, what is gained by having >>> separate certs? >> >> I responded in private email: >> >>> With a POLA architecture, perhaps on a capability OS (dream, dream), >>> they might not share access to the private keys. However, given current >>> software, I grant your point. >> >> Ben responded that I should post my comments to the list. >> >> There are two scenarios I see as being viable for separating the private >> keys with a security barrier. One is the single machine case alluded to >> above. Here the private keys would be in separate security domains, and >> the common part of the web server, which listens on the socket, would >> read the initial data on the TCP connection, select the correct security >> domain, and "pass" the connection to that domain. While the common part >> could continue to examine all the data, those data would be encrypted, >> so the it would have the same access as any other untrusted node in the >> path. >> >> The other scenario involves a network switch which performs the function >> of the common code of the web server. It uses network address >> translation to forward the connection's packets to the back-end computer >> with the correct private key. Here the keys are protected by being kept >> on separate computers. > >This would defeat the reason people share IP addresses, which is so they >can share a single machine to reduce costs. Of course, a capability OS >would permit this whilst separating keys, as you said. > It doesn't have to be a capability-based OS; one could easily envision a (ahem) alternate browser strategy accomplish it. Consider, to pick a non-random example, Apache. Apache 2.0.x (and I think 1.y, but I don't run it so I can't be sure) forks several child processes to actually serve the pages. What if the directives contained an optional User directive that specified the uid each virtual host should run as? You could have different processes for different virtual hosts. Yes, that would require more bookkeeping on the part of Apache; it would also require more (perhaps many more) processes running simultaneously. Both of those are much smaller changes than a capability-based OS. (Hmm -- who was it who noted that capability- based systems were the wave of the future, and always would be?) A final note -- multiple IP addresses is not the same as multiple machines. Lots of hosting companies dedicate an IP address to each customer, but put them all on a single machine. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Bill Frantz wrote: > On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: > >> I don't see why not - the technical details actually matter. Since the >> servers will all share a socket, on any normal architecture, they'll all >> have access to everyone's private keys. So, what is gained by having >> separate certs? > > I responded in private email: > >> With a POLA architecture, perhaps on a capability OS (dream, dream), >> they might not share access to the private keys. However, given current >> software, I grant your point. > > Ben responded that I should post my comments to the list. > > There are two scenarios I see as being viable for separating the private > keys with a security barrier. One is the single machine case alluded to > above. Here the private keys would be in separate security domains, and > the common part of the web server, which listens on the socket, would > read the initial data on the TCP connection, select the correct security > domain, and "pass" the connection to that domain. While the common part > could continue to examine all the data, those data would be encrypted, > so the it would have the same access as any other untrusted node in the > path. > > The other scenario involves a network switch which performs the function > of the common code of the web server. It uses network address > translation to forward the connection's packets to the back-end computer > with the correct private key. Here the keys are protected by being kept > on separate computers. This would defeat the reason people share IP addresses, which is so they can share a single machine to reduce costs. Of course, a capability OS would permit this whilst separating keys, as you said. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
