Nxdomain redirect revenue
Just an fyi for anyone who has a marketing person dreaming up a big nxdomain redirect business cases, the stats are actually very very poor... it does not make much money at all. It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served an ad page because 95%+ of nxd are printer lookups and such that cannot be served an ad page. Then from that less than 5% pool, the click through rates are around 1% Net net, no free money of any meaningful value. But, ymmv... but I don't think by much. Cb
On Sat, Sep 24, 2011 at 9:33 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
Just an fyi for anyone who has a marketing person dreaming up a big nxdomain redirect business cases, the stats are actually very very poor... it does not make much money at all.
It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served an ad page because 95%+ of nxd are printer lookups and such that cannot be served an ad page. Then from that less than 5% pool, the click through rates are around 1%
Net net, no free money of any meaningful value. But, ymmv... but I don't think by much.
that's some interesting data points, thanks!
Cb
On Sat, Sep 24, 2011 at 8:33 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
Just an fyi for anyone who has a marketing person dreaming up a big nxdomain redirect business cases, the stats are actually very very poor... it does not make much money at all. It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served
Not to take any position on there being a "business case" for NXDOMAIN redirect, or not but.... the percentage of NXdomain redirects that actually serve ads isn't too important. It's absolute numbers that matter, even if it's just 1% of NXDOMAINS by percent. The rest of the 99% are referred to as "noise" and aren't relevant for justifying or failing to justify. The important number is at what frequency the _average_ user will encounter the redirect while they are surfing. If a sufficient proportion of their users see the ads at a sufficient rate, then they will probably justify whatever cost they have for the ad serving. When they are doing this crappy stuff like redirecting google.com DNS to intercept search requests; I have little doubt that they are able to inject sufficient volume of ads to make some sort of "business case" behind the hijacking evilness. Regards, -- -JH
On Sunday 25 Sep 2011 04:09:22 Jimmy Hess wrote:
On Sat, Sep 24, 2011 at 8:33 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
Just an fyi for anyone who has a marketing person dreaming up a big nxdomain redirect business cases, the stats are actually very very poor... it does not make much money at all. It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served
Not to take any position on there being a "business case" for NXDOMAIN redirect, or not but.... the percentage of NXdomain redirects that actually serve ads isn't too important. It's absolute numbers that matter, even if it's just 1% of NXDOMAINS by percent.
The rest of the 99% are referred to as "noise" and aren't relevant for justifying or failing to justify.
The important number is at what frequency the _average_ user will encounter the redirect while they are surfing. If a sufficient proportion of their users see the ads at a sufficient rate, then they will probably justify whatever cost they have for the ad serving.
When they are doing this crappy stuff like redirecting google.com DNS to intercept search requests; I have little doubt that they are able to inject sufficient volume of ads to make some sort of "business case" behind the hijacking evilness.
Regards,
-- -JH
I think a special mention should go to hardware vendors who adopt this dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit of intercepting some % of queries to its local DNS cache resolver and forwarding to an affiliate Yahoo! search page, lousy with ads, under vendor D's control. This includes things like www.google.co.uk. I don't manage this device and therefore have opened a ticket with those who do to get them to turn the damn thing off, while in the meantime adding *.[vendor D]search.com 127.0.0.1 to my /etc/hosts. I must admit to being tempted to "fault" it with something heavy in order to force its replacement:-) But if anyone from vendor-D is on the list: congratulations, you've managed to invent a network device that is by definition untrustworthy, and I will never buy anything from your company. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
On 25/09/2011 12:39, Alexander Harrowell wrote:
I think a special mention should go to hardware vendors who adopt this dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit
It is not libellous to associate a vendor's real name with calmly stated matters of objective fact concerning their products. I'd be interested to know the particular model that you're referring to here - like you, to put it on a list of kit that I will never buy. Re: "enterprise-grade" - did you mean this as a compliment or an insult? Nick
On Sun, Sep 25, 2011 at 5:37 PM, Nick Hilliard <nick@foobar.org> wrote:
On 25/09/2011 12:39, Alexander Harrowell wrote:
I think a special mention should go to hardware vendors who adopt this dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit
It is not libellous to associate a vendor's real name with calmly stated matters of objective fact concerning their products.
I would guess he is referring to this "Advanced DNS Security" misfeature : http://www.dslreports.com/forum/r25921912-DLINK-Router-Advanced-DNS-Setup-Ca... -- -JH
On 25/09/2011 12:39, Alexander Harrowell wrote:
I think a special mention should go to hardware vendors who adopt
On Sunday 25 Sep 2011 23:37:20 Nick Hilliard wrote: this
dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit
It is not libellous to associate a vendor's real name with calmly stated matters of objective fact concerning their products.
I'd be interested to know the particular model that you're referring to here - like you, to put it on a list of kit that I will never buy.
Re: "enterprise-grade" - did you mean this as a compliment or an insult?
Nick
It's D-Link, if you hadn't guessed, and it's the DIR series. Regarding "enterprise", these devices are not service provider kit but they're not under-the-TV-set either, and our use-case is basically typical of a branch-office set up. In which the DIR works really well, if it didn't do demented things with DNS. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
* Cameron Byrne:
It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served an ad page because 95%+ of nxd are printer lookups and such that cannot be served an ad page. Then from that less than 5% pool, the click through rates are around 1%
Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.) -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Sep 26, 2011 1:29 AM, "Florian Weimer" <fweimer@bfk.de> wrote:
* Cameron Byrne:
It is very important to ask the redirect partners about yields...
meaning,
you may find that less than 5% of nxdomain redirects can be actually served an ad page because 95%+ of nxd are printer lookups and such that cannot be served an ad page. Then from that less than 5% pool, the click through rates are around 1%
Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.)
I have no experience with hijacking real names, which others have noted is evil. Cb
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Mon, Sep 26, 2011 at 10:25 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Sep 26, 2011 1:29 AM, "Florian Weimer" <fweimer@bfk.de> wrote:
* Cameron Byrne:
It is very important to ask the redirect partners about yields...
meaning,
you may find that less than 5% of nxdomain redirects can be actually served an ad page because 95%+ of nxd are printer lookups and such that cannot be served an ad page. Then from that less than 5% pool, the click through rates are around 1%
Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.)
I have no experience with hijacking real names, which others have noted is evil.
I'm curious, is there some belief that the use of hte nxdomain hijacking/rewriting is actually of use to 'users' ? (I'd seen folk claim that the revenue was super-nice, and also it's super beneficial to users...) I don't happen to believe either of these reasons, cameron's note about checking for the right set of numbers before signing contracts seems to indicate that the revenue wasn't there either... -chris
On Mon, Sep 26, 2011 at 2:11 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 26 Sep 2011 10:36:51 EDT, Christopher Morrow said:
I'm curious, is there some belief that the use of hte nxdomain hijacking/rewriting is actually of use to 'users' ?
"of use to users" is, in general, incompatible with "race to the bottom".
my point is that on the one hand the marketeers say: "This is a great help to your users who are confused by the missing dns entries! They like it! It is a benefit and a comfort to them!" and on the other hand: "You will make lots of mullah from the nxdomain rewriting! it's wonderful!" (plus some mumbling about, why would you want to give that money away to the content providers of the world for free?) -chris (I don't believe that it's a great help, nor that customers actually WANT it, nor that it makes great gobs of money... but I'm willing to be educated)
On Mon, Sep 26, 2011 at 2:17 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Sep 26, 2011 at 2:11 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 26 Sep 2011 10:36:51 EDT, Christopher Morrow said:
I'm curious, is there some belief that the use of hte nxdomain hijacking/rewriting is actually of use to 'users' ?
"of use to users" is, in general, incompatible with "race to the bottom".
my point is that on the one hand the marketeers say: "This is a great help to your users who are confused by the missing dns entries! They like it! It is a benefit and a comfort to them!"
and on the other hand: "You will make lots of mullah from the nxdomain rewriting! it's wonderful!"
s/mullah/moolah/ :( context switch fail.
(plus some mumbling about, why would you want to give that money away to the content providers of the world for free?)
-chris (I don't believe that it's a great help, nor that customers actually WANT it, nor that it makes great gobs of money... but I'm willing to be educated)
On 9/26/11 4:29 AM, Florian Weimer wrote:
Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.)
Has anybody tried bringing a criminal complaint for interference with computer (network) data? Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it? Arguably, substituting a false reply for NXDOMAIN would be, too. It's time to find a champion to lead the charge. Maybe Google?
On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson <william.allen.simpson@gmail.com> wrote: [snip]
Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it?
I would rather see DNSSEC and TLS/HTTPS get implemented end to end. The last thing we need is a court to step in and say "It's not legal for an ISP to blacklist, block, or redirect traffic, to any hostname or IP address." Most likely the ISPs' lawyers were smart enough to include a clause in the ToS/AUP allowing the ISP to intercept, blackhole, or redirect access to any hostname or IP address. The name for an ISP intercepting traffic from its own users is not "interference" or "DoS", because they're breaking the operation of (er) only their own network. The solution is to spread their name as widely as possible, so consumers can make an informed choice if they wish to avoid service providers that engage in abusive practices, and bring it attention to regulators if the service providers are acting as an abusive monopoly in regards to their interception practices. -- -JH
On Tue, Sep 27, 2011 at 7:50 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson <william.allen.simpson@gmail.com> wrote: [snip]
Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it?
I would rather see DNSSEC and TLS/HTTPS get implemented end to end.
how does tls/https help here? if you get sent to the 'wrong host' whether or not it does https/tls is irrelevant, no? (save the case of chrome and domain pinning)
The solution is to spread their name as widely as possible, so consumers can make an informed choice if they wish to avoid service providers that engage in abusive practices, and bring it attention to regulators if the service providers are acting as an abusive monopoly in regards to their interception practices.
sadly, not everyone has a choice in providers :(
On Tue, 27 Sep 2011 09:27:00 EDT, Christopher Morrow said:
On Tue, Sep 27, 2011 at 7:50 AM, Jimmy Hess <mysidia@gmail.com> wrote:
I would rather see DNSSEC and TLS/HTTPS get implemented end to end.
how does tls/https help here? if you get sent to the 'wrong host' whether or not it does https/tls is irrelevant, no? (save the case of chrome and domain pinning)
Well, actually, Chrome-like domain pinning and/or using DNSSEC to verify the provenance of an SSL cert is the whiole reason Jimmy probably wants DNSSEC and TLS...Unless you do that sort of stuff, there's no way to *tell* if you ended up at the wrong host...
On Tue, Sep 27, 2011 at 10:19 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 27 Sep 2011 09:27:00 EDT, Christopher Morrow said:
On Tue, Sep 27, 2011 at 7:50 AM, Jimmy Hess <mysidia@gmail.com> wrote:
I would rather see DNSSEC and TLS/HTTPS get implemented end to end.
how does tls/https help here? if you get sent to the 'wrong host' whether or not it does https/tls is irrelevant, no? (save the case of chrome and domain pinning)
Well, actually, Chrome-like domain pinning and/or using DNSSEC to verify the provenance of an SSL cert is the whiole reason Jimmy probably wants DNSSEC and TLS...Unless you do that sort of stuff, there's no way to *tell* if you ended up at the wrong host...
to paraphrase mo: "this will not scale" (you can't possibly pin everyone that matters (to all users) inside the binary) It's a cute intermediate trick until the CA problem is resolved/executed and DNSSEC arrives in full (on the service AND client side). -chris
On Tue, Sep 27, 2011 at 8:27 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
how does tls/https help here? if you get sent to the 'wrong host' whether or not it does https/tls is irrelevant, no? (save the case of chrome and domain pinning)
Because the operator of the "wrong host" cannot obtain a SSL certificate for the right host's domain from a legitimate CA. When the user types in '[therightdomain].com' and their browser immediately sends them to https://therightdomain.com the HTTPS request will fail and show the user an error message if the site is the wrong one, instead of allowing the wrong server to produce a response. To be clear, I am suggesting HTTPS should be the default, all servers should support it, and once a browser learns that a site supports HTTPS, it should maintain a memory of that fact in a hash table, and refuse to access the site over HTTP unless specifically requested (in order to prevent downgrade attacks) and refuse to try HTTP first when a new domain is entered. The http:// schema should be removed/deprecated, and replaced with insecurehttp:// And plain HTTP only used first if the user types that. That is, HTTPs should become assumed. Regards, -- -JH
On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia@gmail.com> wrote:
That is, HTTPs should become assumed.
As much as that would be wonderful from a security standpoint, IMO it's not realistic to expect every mom-and-pop posting a personal Web site to pay extra for a static/dedicated IP address from their hosting company (even if IPv6 were widely deployed, Web hosts probably would charge extra for this just on principle), and to pay extra for an SSL certificate, even a "weak" one that only verifies the domain name. If a given Web site's developers think their content is "important" (however they define the term), they certainly can add SSL to the site; in the grand scheme of things the cost is pretty small. But assuming everyone can/should do this is probably a step too far. That said, there's nothing wrong with browser extensions that try HTTPS first, and I'd wager that sooner or later one of the big browsers will make that a built-in option. David Smith MVN.net
On Tue, Sep 27, 2011 at 5:29 PM, David E. Smith <dave@mvn.net> wrote:
On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia@gmail.com> wrote:
That is, HTTPs should become assumed. As much as that would be wonderful from a security standpoint, IMO it's not realistic to expect every mom-and-pop posting a personal Web site to pay extra for a static/dedicated IP address from their hosting company (even if IPv6 were widely deployed, Web hosts probably would
Thanks to TLS SNI (server name indication), a dedicated IP address is no longer necessarily, RFC 3546, 3.1. Yes, it is realistic to expect every mom-and-pop posting a personal web site to utilize a provider that implements SNI, and the sooner they do it. It's also realistic to expect them to buy one of those $15 SSL certificates. Heck.... 1 year .COM registration used to cost a lot more than that. We're not talking about huge recurring costs here. -- -JH
On Sep 27, 2011, at 3:46 PM, Jimmy Hess wrote:
On Tue, Sep 27, 2011 at 5:29 PM, David E. Smith <dave@mvn.net> wrote:
On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia@gmail.com> wrote:
That is, HTTPs should become assumed. As much as that would be wonderful from a security standpoint, IMO it's not realistic to expect every mom-and-pop posting a personal Web site to pay extra for a static/dedicated IP address from their hosting company (even if IPv6 were widely deployed, Web hosts probably would
Thanks to TLS SNI (server name indication), a dedicated IP address is no longer necessarily, RFC 3546, 3.1.
Except when it is.
Yes, it is realistic to expect every mom-and-pop posting a personal web site to utilize a provider that implements SNI, and the sooner they do it.
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
It's also realistic to expect them to buy one of those $15 SSL certificates. Heck.... 1 year .COM registration used to cost a lot more than that.
Meh... I disagree. I don't think there's any reason to encrypt web sites that don't use authentication and are not providing personally identifying information or other "secret" data. I run several web servers virtual and real on one of my systems. Some of them have SSL, some of them don't. Even the ones that have SSL don't encrypt everything. There's no reason to encrypt that which does not need encryption and it's just an extra cost in terms of server resources and client resources to do so.
We're not talking about huge recurring costs here.
That depends. If it's a popular web site that delivers a lot of content, the additional CPU horsepower just to do the cryptography and the additional power to drive it could actually be very significant. For the average mom and pop, no, it's not a huge cost, but, neither is it necessarily a cost worth bothering with. Frankly, I don't expect static (or at least static-enough) addresses to cost extra in IPv6. You can already get a /48 from Hurricane Electric for free as long as you have IPv4 access. I suspect that eventually other IPv6 providers will have to at least match that standard. Owen
On Tue, Sep 27, 2011 at 6:09 PM, Owen DeLong <owen@delong.com> wrote:
On Sep 27, 2011, at 3:46 PM, Jimmy Hess wrote:
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
That's OK. You're kind of mincing security objectives here. In regards to preventing tactics such as domain hijacking bt service providers, the goal behind this would be integrity, not confidentiality. The objective of using SSL is not to strongly encrypt data to keep it secret, it's to apply whatever is necessary to provide a level of integrity assurance. The SSL cipher can almost be the null cipher, for all it matters, but at least RC4 56-bit or so would be needed, because the null cipher doesn't have message digests in TLS. -- -JH
On Sep 27, 2011, at 4:55 PM, Jimmy Hess wrote:
On Tue, Sep 27, 2011 at 6:09 PM, Owen DeLong <owen@delong.com> wrote:
On Sep 27, 2011, at 3:46 PM, Jimmy Hess wrote:
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
That's OK. You're kind of mincing security objectives here. In regards to preventing tactics such as domain hijacking bt service providers, the goal behind this would be integrity, not confidentiality.
The objective of using SSL is not to strongly encrypt data to keep it secret, it's to apply whatever is necessary to provide a level of integrity assurance.
The SSL cipher can almost be the null cipher, for all it matters, but at least RC4 56-bit or so would be needed, because the null cipher doesn't have message digests in TLS.
-- -JH
As has been pointed out... SSL certs do almost nothing for integrity. Owen
<snip> On 09/27/2011 07:55 PM, Jimmy Hess wrote:
the goal behind this would be integrity, not confidentiality. The objective of using SSL is not to strongly encrypt data to keep it secret, it's to apply whatever is necessary to provide a level of integrity assurance.
</snip> If all you want is integrity then shouldn't you argue that every computer should operate a DNSSEC validating recursive resolver on the machine? After all that is the point of DNSSEC after all isn't it, the validation of DNS records for endpoint authenticity. Even still SNI isn't even widely supported by the major browsers as I understand it. just my 2c
On Tue, Sep 27, 2011 at 04:09:03PM -0700, Owen DeLong wrote:
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
And speaking https to a per-domain ip address reveals nothing about browsing habits?
Once upon a time, Owen DeLong <owen@delong.com> said:
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
If you don't want even the site you are browsing public, HTTPS is not the solution. Without SNI, HTTPS is one-site-per-IP (nobody uses the subjectAltName to host multiple different sites on the same IP in practice), so all somebody has to do it fetch the certificate from the same IP/port and look at the CN/subjectAltName. Either that's the site you went to, or you accepted the host/cert mismatch (and are a target for spoofing). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Tue, Sep 27, 2011 at 04:09:03PM -0700, Owen DeLong wrote:
Yes, it is realistic to expect every mom-and-pop posting a personal web site to utilize a provider that implements SNI, and the sooner they do it.
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
That's what happens without SNI. Without SNI, the IP address of the server is sent in the clear; anyone who captures that traffic knows the IP address, and, without SNI, anyone who want s to translate the IP address to a domain name need only connect to the server and see what certificate is presented. -- Brett
On Tue, 27 Sep 2011 16:09:03 PDT, Owen DeLong said:
No, it isn't because it requires you to send the domain portion of the URL in clear text and it may be that you don't necessarily want to disclose even that much information about your browsing to the public.
If that's an actual concern, I suggest you talk to the nice people at https://www.torproject.org/ - and remember that tor was originally designed by the US government so our spooks could fly under the wire, so it's patriotic to run a tor relay. ;)
On Tue, Sep 27, 2011 at 7:29 PM, David E. Smith <dave@mvn.net> wrote:
On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia@gmail.com> wrote:
That is, HTTPs should become assumed.
As much as that would be wonderful from a security standpoint, IMO it's not realistic to expect every mom-and-pop posting a personal Web site to pay extra for a static/dedicated IP address from their hosting company (even if IPv6 were widely deployed, Web hosts probably would charge extra for this just on principle), and to pay extra for an SSL certificate, even a "weak" one that only verifies the domain name.
Self-signed certificates published thru DNSSEC using CAA/DANE can cost nothing. (And somebody else pointed out SNI to have TLS work without exclusive IP requirement) Rubens
+1 to the use of CAA/DANE -brian On 09/27/2011 07:34 PM, Rubens Kuhl wrote:
On Tue, Sep 27, 2011 at 7:29 PM, David E. Smith<dave@mvn.net> wrote:
On Tue, Sep 27, 2011 at 17:08, Jimmy Hess<mysidia@gmail.com> wrote:
That is, HTTPs should become assumed. As much as that would be wonderful from a security standpoint, IMO it's not realistic to expect every mom-and-pop posting a personal Web site to pay extra for a static/dedicated IP address from their hosting company (even if IPv6 were widely deployed, Web hosts probably would charge extra for this just on principle), and to pay extra for an SSL certificate, even a "weak" one that only verifies the domain name. Self-signed certificates published thru DNSSEC using CAA/DANE can cost nothing. (And somebody else pointed out SNI to have TLS work without exclusive IP requirement)
Rubens
On Tue, Sep 27, 2011 at 05:08:42PM -0500, Jimmy Hess wrote:
On Tue, Sep 27, 2011 at 8:27 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
how does tls/https help here? if you get sent to the 'wrong host' whether or not it does https/tls is irrelevant, no? (save the case of chrome and domain pinning)
Because the operator of the "wrong host" cannot obtain a SSL certificate for the right host's domain from a legitimate CA.
Oh, if only 'twere true... even without control of the DNS for the domain, there have been plenty of certificates erroneously issued. With DNS control, doing the necessary validation steps required for the issuance of a certificate is child's play. Then, of course, there's the issues with what constitutes a "legitimate" CA; the list of CAs that I'd never want to trust, but which are in my browser by default, is long and notorious. - Matt
On 9/27/11 7:50 AM, Jimmy Hess wrote:
On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson <william.allen.simpson@gmail.com> wrote: [snip]
Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it?
I would rather see DNSSEC and TLS/HTTPS get implemented end to end.
They are.
The last thing we need is a court to step in and say "It's not legal for an ISP to blacklist, block, or redirect traffic, to any hostname or IP address."
Don't distort my words. It amuses me when so-called conservative cyber-libertarians hate the idea of courts stepping in to enforce laws, except the laws governing their own contracts enforcing payments regardless of the quality of their goods. The cable and satellite industry forced through digital protection acts -- to protect their revenue streams. Now, it's time to use those acts against them. It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense. It's not legal for a vendor to sell or give away equipment that aids interception and modification of data. That's a criminal offense.
Most likely the ISPs' lawyers were smart enough to include a clause in the ToS/AUP allowing the ISP to intercept, blackhole, or redirect access to any hostname or IP address.
It's not legal to insert a clause allowing criminal conduct. There's no safe haven for criminal conduct.
The name for an ISP intercepting traffic from its own users is not "interference" or "DoS", because they're breaking the operation of (er) only their own network.
No, they're breaking the operation of my network and my computers. My network connects to their network.
The solution is to spread their name as widely as possible, so consumers can make an informed choice if they wish to avoid service providers that engage in abusive practices, and bring it attention to regulators if the service providers are acting as an abusive monopoly in regards to their interception practices.
There are no choices. They *are* abusive monopolies. Why are "regulators" better than courts? After all, the regulators will also involve courts.
On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense.
Citation? Hint - a *big* chunk of ISPs have NAT deployed, and that's messing with packet headers. Much as many of us would like to see NAT go away, I don't think we want an environment where deploying NAT gets us a new roommate and best friend named Bubba. Oh, and if you're not modifying the TTL field, you're Doing It Wrong.
It's not legal for a vendor to sell or give away equipment that aids interception and modification of data. That's a criminal offense.
Again, citiation? Meanwhile, CALEA *requires* you to have a network that aids in at least the interception of data. What's a poor ISP to do?
On Tue, Sep 27, 2011 at 11:48 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense.
Citation?
Could tampering with DNSSEC and/or TLS fall into DMCA grounds ? Rubens
On 9/27/2011 11:41 AM, Rubens Kuhl wrote:
On Tue, Sep 27, 2011 at 11:48 AM,<Valdis.Kletnieks@vt.edu> wrote:
On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense. Citation? Could tampering with DNSSEC and/or TLS fall into DMCA grounds ?
Doubtful. DMCA (the C is Copyright) protects copyright owners. I have never seen anyone claim copyright over their DNS records. Interesting thought, but copyright law is a tangled mess that I would guess is probably the wrong tactic if someone were planning to legally oppose/attack service providers using NXDOMAIN redirection. Also, only the 'owner' of a copyright can bring suit. -DMM
On 9/27/11 11:41 AM, Rubens Kuhl wrote:
On Tue, Sep 27, 2011 at 11:48 AM,<Valdis.Kletnieks@vt.edu> wrote:
On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense.
Citation?
Could tampering with DNSSEC and/or TLS fall into DMCA grounds ?
Good thought, but I was thinking more along the lines of UETA and E-SIGN, along with the usual criminal penalties for forgery and fraud (and intent to defraud). I'm pretty sure those are state by state. On the US Federal level, there's 18 USC 2511 - Interception and disclosure of wire, oral, or electronic communications prohibited. In any case, there's plenty of law to choose, we simply need a solid test case. Family members are Wide Open West (WOW) subscribers, and they are listed among the miscreant companies that Heather linked. I'd happily be a plaintiff based on my use of their network, but we probably need some actual affected subscribers.
It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense.
It is indeed illegal to break into someone's else's computer and tamper with the data therein. It is frankly ridiculous to try to apply that law to data in your own equipment. If you think computer tampering laws apply to the operation of one's own DNS cache, provide case law. For case law confirming that similar language in the Stored Communication Act doesn't apply to data on your own equipment, see the recently dismissed cases of Holomaxx vs. Microsoft and Holomaxx vs. Yahoo. R's, John PS: Can we stop playing Junior Lawyer now?
On 27/09/2011 19:31, John Levine wrote:
For case law confirming that similar language in the Stored Communication Act doesn't apply to data on your own equipment, see the recently dismissed cases of Holomaxx vs. Microsoft and Holomaxx vs. Yahoo.
In Europe, things are slightly different. Traffic snooping is considered to be a breach of consumer data protection directives and is treated accordingly. One of the more interesting cases was BT + Phorm:
http://en.wikipedia.org/wiki/Phorm#European_Commission_case_against_UK_over_...
While the case never went to court, all parties backed down and there hasn't been a similar case since then. There is another aspect to this: european IP service providers can claim "mere conduit" status (similar to US "common carrier") under the terms of the Electronic Commerce Directive 2000/31/EC (as transcribed into local legislation), provided during the process of transmission they do "not select or modify the information contained in the transmission". It would seem possible that changing DNS packets in transit could come under the scope of "select or modify", thereby leaving the IP service provider liable for the information transmitted. This can act as a deterrent to service providers who feel that modifying data in-flight is a good idea. Nick
On 27/09/11 7:20 AM, William Allen Simpson wrote:
Most likely the ISPs' lawyers were smart enough to include a clause in the ToS/AUP allowing the ISP to intercept, blackhole, or redirect access to any hostname or IP address.
It's not legal to insert a clause allowing criminal conduct. There's no safe haven for criminal conduct.
I'm not sure that it's *illegal to insert a clause* for conduct that is forbidden by law. I'm pretty sure you can claim almost anything in the contract. What is illegal is enforcement of an illegal clause. Law trumps contract terms - that's WHY we have civil laws - to protect people from unscrupulous business dealings. And that's why most contracts have a clause that says if a particular clause in the contract is found invalid the rest of the contract still stands - because so many contracts DO have invalid clauses. For example, many employment contracts have non-compete clauses that forbid the employee from going to work for a competitor. But in many states these clauses violate the state's right-to-work laws. The company lawyers KNOW the clause is illegal, but they insert it in the employment contracts anyway, to try to fool employees into thinking they will get sued if they go to work for a competitor.
The name for an ISP intercepting traffic from its own users is not "interference" or "DoS", because they're breaking the operation of (er) only their own network.
No, they're breaking the operation of my network and my computers. My network connects to their network.
But you have no recourse, their network, their rules. (Right?) You *might* have recourse if they were modifying traffic you sent to their customer, but in this case they are modifying traffic that originates FROM their customer. I'm not convinced that redirecting this traffic is any different from blocking it (e.g. firewall to prevent employees from accessing facebook or torrents). I believe the only entity who has recourse is the entity who is paying them for service - e.g. their (paying) customer. jc
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Tue Sep 27 15:54:37 2011 Date: Tue, 27 Sep 2011 13:54:26 -0700 From: JC Dill <jcdill.lists@gmail.com> To: NANOG list <nanog@nanog.org> Subject: Re: Nxdomain redirect revenue
On 27/09/11 7:20 AM, William Allen Simpson wrote:
Most likely the ISPs' lawyers were smart enough to include a clause in the ToS/AUP allowing the ISP to intercept, blackhole, or redirect access to any hostname or IP address.
It's not legal to insert a clause allowing criminal conduct. There's no safe haven for criminal conduct.
I'm not sure that it's *illegal to insert a clause* for conduct that is forbidden by law. I'm pretty sure you can claim almost anything in the contract. What is illegal is enforcement of an illegal clause. Law trumps contract terms - that's WHY we have civil laws - to protect people from unscrupulous business dealings. And that's why most contracts have a clause that says if a particular clause in the contract is found invalid the rest of the contract still stands - because so many contracts DO have invalid clauses. For example, many employment contracts have non-compete clauses that forbid the employee from going to work for a competitor. But in many states these clauses violate the state's right-to-work laws. The company lawyers KNOW the clause is illegal, but they insert it in the employment contracts anyway, to try to fool employees into thinking they will get sued if they go to work for a competitor.
The name for an ISP intercepting traffic from its own users is not "interference" or "DoS", because they're breaking the operation of (er) only their own network.
No, they're breaking the operation of my network and my computers. My network connects to their network.
But you have no recourse, their network, their rules. (Right?) You *might* have recourse if they were modifying traffic you sent to their customer, but in this case they are modifying traffic that originates FROM their customer. I'm not convinced that redirecting this traffic is any different from blocking it (e.g. firewall to prevent employees from accessing facebook or torrents).
I believe the only entity who has recourse is the entity who is paying them for service - e.g. their (paying) customer.
In the specific case of 'falsifying' a DNS return for what would have been a NXDOMAIN, that is "mostly' correct. but consider whqat happens when you get into the situation of querying a DNSBL operator -- where an 'error' result _is_ a desired return value. Now, when the provider returns 'false and misleading' data for what would be, under normal conditions, a SUCCESSFUL query -- say, returning a 'bogus' address for a well-known search-engine, so as to bee able to manipulate the results -- then the party whose traffic is being 'stolen', and sent to the bogus server, THAT party may well have grounds for a civil suit for 'tortuous interference with a business relationship'. In this situation, there are also possible criminal sanctions, under 'wiretapping' prohibitions, among others.
Jimmy, On Tue, Sep 27, 2011 at 1:50 PM, Jimmy Hess <mysidia@gmail.com> wrote:
The name for an ISP intercepting traffic from its own users is not "interference" or "DoS", because they're breaking the operation of (er) only their own network.
This statement somehow assumes that users of said network were only intending to communicate within that same network. I think this applies to so few networks it can be ignored in the discussion. If I have a partner/customer/supplier/$foo in [common carrier/public carrier] network X, and there is no D/DoS or other form of abuse ongoing, and the operator of X willfully denies our communication, the operator of X should have pretty darn good reasons for doing so (on the order of having been ordered by the proper judicial system (which should be well-functional, but that's a bit out of scope for the discussion I guess)). Operators should take great care to not break communication, including tampering with internet architectures such as DNS, and it must be possible to hold those who do responsible for their actions. Regards, Martin
On Wed, Sep 28, 2011 at 2:26 PM, Martin Millnert <millnert@gmail.com> wrote: Hi, I think you're echoing a common misconception here:
If I have a partner/customer/supplier/$foo in [common carrier/public carrier] network X, and there is no D/DoS or other form of abuse
ISPs are not like traditional telephone carriers. ISPs are not common carriers. They are not common carriers legally, and they are not _like_ common carriers operationally. They are empowered to provide whatever types of service and service levels to their subscriber that their properly agreed upon terms of service provides for.... Most end users of an ISP don't even get a SLA, let alone a promise that any IP address will be reachable. Also, thanks to peering spats and other various phenomena, it's actually an impossible promise for an ISP to make. Due to the nature of the internet ISPs _often_ make decisions that result in discrimination of traffic based on its type, its source, destination, payload contents, etc. Blackholing spammer IP addresses is a common example; and ISPs could not do that if they were common carriers.
ongoing, and the operator of X willfully denies our communication, the operator of X should have pretty darn good reasons for doing so (on
In your opinion the operator should have a "pretty darn good reason" for doing so. But in reality, the internet service subscriber's subscription agreement will state what's a "pretty darn good reason"; generally, the agreement states that any reason at all, or no reason, solely at the operator's discretion, is good enough.
Operators should take great care to not break communication, including tampering with internet architectures such as DNS, and it must be possible to hold those who do responsible for their actions.
It occurs that an ISP deploying a custom DNS service that implements their own policies of munging redirects or producing "false" answers is not "tampering" with anyone else's server. -- -JH
Paxfire gets sued: http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-... http://www.courthousenews.com/2011/08/08/38796.htm http://www.pcmag.com/article2/0,2817,2390529,00.asp Paxfire files counter suit: http://www.techdirt.com/articles/20110809/17305215460/paxfire-responds-says-... http://www.techdirt.com/articles/20110906/03371515808/paxfire-sues-lawyers-i... http://www.prweb.com/releases/2011/9/prweb8765163.htm -----Original Message----- From: William Allen Simpson [mailto:william.allen.simpson@gmail.com] Sent: Tuesday, September 27, 2011 4:58 AM To: nanog@nanog.org Subject: Re: Nxdomain redirect revenue On 9/26/11 4:29 AM, Florian Weimer wrote:
Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.)
Has anybody tried bringing a criminal complaint for interference with computer (network) data? Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it? Arguably, substituting a false reply for NXDOMAIN would be, too. It's time to find a champion to lead the charge. Maybe Google?
On 9/26/11 4:29 AM, Florian Weimer wrote: Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.)
I responded:
Has anybody tried bringing a criminal complaint for interference with computer (network) data?
Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it?
Arguably, substituting a false reply for NXDOMAIN would be, too.
It's time to find a champion to lead the charge. Maybe Google?
On 9/27/11 12:34 PM, Schiller, Heather A top posted:
Paxfire gets sued: http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-... http://www.courthousenews.com/2011/08/08/38796.htm http://www.pcmag.com/article2/0,2817,2390529,00.asp
Paxfire files counter suit: http://www.techdirt.com/articles/20110809/17305215460/paxfire-responds-says-... http://www.techdirt.com/articles/20110906/03371515808/paxfire-sues-lawyers-i... http://www.prweb.com/releases/2011/9/prweb8765163.htm
Thanks, Heather, I didn't know/remember about the civil suit. Good start. But I'm talking about criminal. They're different.
participants (22)
-
Alexander Harrowell -
Brett Frankenberger -
Brian Smith -
Cameron Byrne -
Chris Adams -
Christopher Morrow -
David E. Smith -
David Miller -
Florian Weimer -
JC Dill -
Jimmy Hess -
John Levine -
Jussi Peltola -
Martin Millnert -
Matthew Palmer -
Nick Hilliard -
Owen DeLong -
Robert Bonomi -
Rubens Kuhl -
Schiller, Heather A -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson