It was earlier than that. Around 92, 93. It was a ISP in california and seemed (or claimed) to have some exclusing peering. I remember because I was with digex and they were refusing to pay and urging other ISP to do the same.
what next charging someone for receiving a phone call.
You do pay for receiving calls on your land line, you just don't see it in your bill. It's part of your basic service. When you make a call from Verizon to Bell South, Bell South charges Verizon a reciprocal charge for the use of thier services. The same thing happens in reverse. It's a way to exact charges for one providers use of thier network. I imagine for voice calls, this all balances out each month (mostly).
There was a big bruhahaha (and I don't know how it ended) when the Internet started taking off, companies were setting up managed modem banks (charging companies to manage thier modems for them) and ISP services as CLECS. Since they were a CLEC, they also received reciprocal charges from other telcos for using thier equipment but since they didn't mkae outbound calls, they didn't pay reciprocal charges to other telcos.
Talking to one of the founders of such a service, he told me that receiving reciprocal charges is where the money was at. The subscription rates were chump change in comparison.
Yeah, but what about reciprocal charges? In the POTS world, you paid your phone company and for every call that terminited on a different carrier, that carrier paid your phone company a small amount for using thier resources? It all evened out the at the end of the month (well, until modem bank services tipped the balance because they reaped the benefit of all the in-coming calls being charged back without making any outgoing calls)
In a case where an ISP is charging content providers for service to that same ISPs customers, well, that I think is wrong. But what if an ISP is a hop or two between the content provider and consumer and doesn't receive money from either the content provider or consumer? The intervening ISP ships that data for free and the only benefit is the result of a gentlemans agreement that other ISPs will ship thier customers data (content provider or consumer) for free.
I recall that back in the early 90's, there was a ISP that wanted to charge other ISP for access to the networks and services they hosted. I don't think that lasted all that long. Anyone recall the ISP? I am at a loss.
If you haven't deployed a PKI yet, what is stopping you?
There are a bunch of reasons. Setting up a PKI is relatively simple once you go through the very difficult part of deciding what you want to accomplish, set up the requisite documents like a certificate management policy.
The biggest challenge is certificate management. Everything from enrollement, updates, revocation, key escrow, and mobility. MS certificate server is very bare bones and good at what it was designed to do--issue certificates to Windows computers. Anything beyond that is difficult.
Set past certificate management, and you get into applications into application integration issues. It's not always enough to simply enroll an application with a certificate. You have to manage revocation of which there are 3 common methods, CRL, CRDP, and OCSP. Then you have to apply things in the application like path management. You don't always all certificates to be accepted by all applications, especially if you get into a more complex PKI situation. That's just server side.
Then there are the client issues. A common PKI application is S/MIME. That's fine for internal email, but one you get beyond your borders, you have to integrate with partners or your customers, it get's to be a real mess. Do you issue certificates to partners? How do you trust their certificates? Cross certify? Import thier signing CA certificate? What about revocation? That's just for S/MIME. More interesting applications are more difficult.
And finally what do you get with digital certificate? Better authentication? Most likely not because when that certificate is generated, the proviate key is placed in the local certificate store. How is that protected? By a password? Usually not even by that! Usually the certificate store is wide open for *usabiity*. You don't gain much with a PKI unless it is comletely managed.
Someone else mentioned other CA vendors like RSA and Verisign. If you really want a manageable PKI that will give you appreciable increases in security, you should really look into a commercial PKI. Simple stuff, MS Cert Serv is fine, but for enterprise PKI, it fails.
Get an FM3 if you can. More expensive than an FM10, but it has aperture priority metering for snappys and when you loose batteries, it will still shoot from B to 1/4000. That's right, full shutter range with no juice. I couldn't be happier, especially on those -5f days outside.
Back in the day, crypto was classified as munitions under ITAR.
Yeah, and it was actually easier to import strong crypto than export it, so alot of companies outside the US became very popular with the security vendors not only for the talentthat exists internationally, but also for the import capabiity.
Yeah, but that doesn't mean it has to be in production. Many mega corps like IBM, MS, HP, etc, are patent engines. They come up with cool ideas, build a prototype, and presto, the "new machine" requirements is compete!
Yeah, and that is especially a concern with all the DNS registrars. Can they be trusted to really identify that some one is who they say they are beyond taking the information off of a credit card statement?
But if your ISPs DNS has been poisoned, then the attacker can resolve any host to the IP address of thier choice. If I control your ISP DNS server and I tell it that www.amazon.com resolves to 192.168.10.1 which is a web server I control, then I can send you a certificate claiming to be from www.amazon.com, and the DNS name will match the FQDN in the certificate. That wouldn't be a problem.
You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place. But that is a different problem altogether.
SecDNS doens't address poor set-up. It attemtps to assert zone authority through record signing. Right now, you don't know if DNS is resolving the correct address or not which makes poisoning such a nasty threat.
RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole.com zone before they begin to expire. Anyone know any different?
You still don't know what application is sending requests, you only know what protocol it is speaking. But so what? sure it just looks like standard http/ssl traffic
The point about SSL is that the data is encrypted and an application layer firewall can't look into the payload. So I probably wasn't clear about why I reccomended an SSL Proxy. Try it this way. The SSL Proxy decrypts and re-encrypts traffic between the client and the server. Prior to passing the now unencrypted traffic to the other side, inspect it to make sure it is, in this case, valid HTTP traffic, versus, say, a terminal session encalsulated in SSL/TLS. If it is valid HTTP, you can also look for well-known mime-types to block certain types of traffic like file sharing, etc.
Your comments about "service level attacks" that break the protocol specification are out of place here too.
Ok, I was being clear about how "application level firewall" can be defined. In some cases, an application level firewall is really just a generic proxy that proxies TCP connection without regard to upper level protocols. Generic proxies thwart network level attacks (layer 3). Application level proxies that proxy service applications like HTTP, FTP, SSH, SMTP, POP3, IMAP regardless of the destination port 1) instantiate (partially or fully depending on the applicaiton layer firewall) the application service and 2) can enforce protocol conformance, block or allow methods, MIME types, and other protocol stuff. Examples of these types of firewalls are Secure Computing Sidewinder, Symantec EFS, and Cyberguard. Application level proxies can also be defined as proxies that make decisions based on data in the application payload like "don't allow SQL injection", "block XSS", and "make sure the XML is well formed and adheres to its DTD." Examples of these types of application level firewalls are Imperva, F5, and Teros.
What you are suggesting is not just difficult - it is impossible (for well designed malware).
Huh? Sure it is possible. Application proxies have been around for a long, long time. Secure Computing has one, as does Cyberguard, and Symantec. Now in thier cases, "application level" enforces the layer 7 and downward protocols for some services, not all. For example, they all have HTTP, FTP, SMTP, IMAP, and POP3 application level proxies. Some support Oracle's SQL*Net V1 or V2. Others support H.323 but not SIP. Anyway, service level attacks such as trying to overflow a buffer, generally will not work through application level proxies because service level attacks tend to violate the protocol specification (binary data where RFC-822 data should be) or violates sane behavior of the protocol, like a HTTP/1.1 host: header longer than 100 characters.
So your wondering about SSL? How about using an HTTP/SSL Proxy and forcing all outbound connections through the proxy and examining the underlying protocols prior to exiting a perimeter firewall? Let's face, the way SSL is used today doesn't provide that much protection anyway (hint: how do you know the certificate from amazon.com is valid? Because you have the public signing certificate from Verisign that was used to sign teh certificate from amazon.com? How did you get Verisign certificate and how do you know *it* is valid? More importantly, how do you know a malicious signing certificate hasn't been inserted into your supposed trusted certificate store? Sorry, that isn't the hint, it's the answer) so you you really don't loose much by using an SSL proxy.
What is more difficult, is application level firewalls that protect web applications (instantiated within the HTML, XML, etc flying back and forth) from malicious use like SQL injection, cooking and field tampering, and yes, buffer overflows. But it can be done.
Home Routers/Firewalls protect your machine against INBOUND, unsolicited connection requests.
That is not correct. Typical home routers are Network Address Port Translation (NAPT) devices that translate private internal addres to a singel public external address. Stopping unsolicited external connections is a beneficial side-effect of NAPT because there is no translation rule for the NAPT router to pass traffic inward. Now, many NAPT routers can't properly handle dynamic protocols like gaming protocoals (specirfically gaming protocols that use ephemeral ports from external hosts (VoIP suffers from this too, btw)), so without specific game support (on a per title or service basis), you essentially create a default inbound rule that says "any external unsolicted connection gets sent to this internal computer."
Software firewalls protect you against OUTBOUND connections you did not authorize.
Wrong again. Host firewalls will block unsolicted external connections to the host and in fact was the original design goal of BlackICE, Zone, and others. Check it out. Turn one on, scan it and see what happens. Then turn off the host firewall, scan it, and compare the results. The blocking of outbound connections came later, as a feature to stop worms and network viruses from spreading.
So if your doing on-line games and your router doesn't intelligently support the gaming protocol (assuming the gaming protocol uses ephemeral ports), then your host is a sitting duck.
Seriously, I know alot of lawyers that are also in IT in some fashion--programmer, net admin, etc. Being a lawyer who understands technology is great pairing of skills.
You are wrong on both counts and you are spreading FUD.
The global warming threat is far from confirmed. There is overwhelming evidence to the contrary. And there have been catastrophic events to the Internet (not including the AOL invasion (ok, karma whore cheap shot. Laugh, it's supposed to be funny)). Remember Slammer, Melissa, and a handful of other fast moving worms that took out large portions of the network for several hours at a time? That was pretty catastrpohic. However, let's also remember that those events were pretty much mitigated within a day or two.
About the only thing that is really going to threaten the "Internet" is taking out the NAPs.
This is the first year that they are pulling out specifically application and network devices/software. However, to anyone who reads Bugtraq, Full Disclosure, or VulnWatch, this is incredibly old news.
I suspect that the new attention is partly due to marketing and partly due to better tracking facilities by ISC.
Feed a server carefully crafted, malformed packets and it may behave in unpredictable ways. We show that several IPSec implementations of IKE V1 don't behave properly.
Not news kids, just development as usual.
Oh, and I like the bit about "possibly executing code." That, I believe, is FUD. Prove that you can execute code.
the whole freakin' point of a small business is that they don't do business in multiple states
Hi, there is thing new thing called the I-n-t-e-r-n-e-t. Maybe you have seen it. It's quite cool. I think it is owned by Microsoft. Or at least they invented it because they have that Explorer thing.
Anyway, you should check it out because, like, I can buy stuff across the world without even making a phone call!
Slashdot Mirror
It was earlier than that. Around 92, 93. It was a ISP in california and seemed (or claimed) to have some exclusing peering. I remember because I was with digex and they were refusing to pay and urging other ISP to do the same.
Not AOL eihter. Thanks though.
what next charging someone for receiving a phone call .
You do pay for receiving calls on your land line, you just don't see it in your bill. It's part of your basic service. When you make a call from Verizon to Bell South, Bell South charges Verizon a reciprocal charge for the use of thier services. The same thing happens in reverse. It's a way to exact charges for one providers use of thier network. I imagine for voice calls, this all balances out each month (mostly).
There was a big bruhahaha (and I don't know how it ended) when the Internet started taking off, companies were setting up managed modem banks (charging companies to manage thier modems for them) and ISP services as CLECS. Since they were a CLEC, they also received reciprocal charges from other telcos for using thier equipment but since they didn't mkae outbound calls, they didn't pay reciprocal charges to other telcos.
Talking to one of the founders of such a service, he told me that receiving reciprocal charges is where the money was at. The subscription rates were chump change in comparison.
Yeah, but what about reciprocal charges? In the POTS world, you paid your phone company and for every call that terminited on a different carrier, that carrier paid your phone company a small amount for using thier resources? It all evened out the at the end of the month (well, until modem bank services tipped the balance because they reaped the benefit of all the in-coming calls being charged back without making any outgoing calls)
In a case where an ISP is charging content providers for service to that same ISPs customers, well, that I think is wrong. But what if an ISP is a hop or two between the content provider and consumer and doesn't receive money from either the content provider or consumer? The intervening ISP ships that data for free and the only benefit is the result of a gentlemans agreement that other ISPs will ship thier customers data (content provider or consumer) for free.
I recall that back in the early 90's, there was a ISP that wanted to charge other ISP for access to the networks and services they hosted. I don't think that lasted all that long. Anyone recall the ISP? I am at a loss.
If you haven't deployed a PKI yet, what is stopping you?
There are a bunch of reasons. Setting up a PKI is relatively simple once you go through the very difficult part of deciding what you want to accomplish, set up the requisite documents like a certificate management policy.
The biggest challenge is certificate management. Everything from enrollement, updates, revocation, key escrow, and mobility. MS certificate server is very bare bones and good at what it was designed to do--issue certificates to Windows computers. Anything beyond that is difficult.
Set past certificate management, and you get into applications into application integration issues. It's not always enough to simply enroll an application with a certificate. You have to manage revocation of which there are 3 common methods, CRL, CRDP, and OCSP. Then you have to apply things in the application like path management. You don't always all certificates to be accepted by all applications, especially if you get into a more complex PKI situation. That's just server side.
Then there are the client issues. A common PKI application is S/MIME. That's fine for internal email, but one you get beyond your borders, you have to integrate with partners or your customers, it get's to be a real mess. Do you issue certificates to partners? How do you trust their certificates? Cross certify? Import thier signing CA certificate? What about revocation? That's just for S/MIME. More interesting applications are more difficult.
And finally what do you get with digital certificate? Better authentication? Most likely not because when that certificate is generated, the proviate key is placed in the local certificate store. How is that protected? By a password? Usually not even by that! Usually the certificate store is wide open for *usabiity*. You don't gain much with a PKI unless it is comletely managed.
Someone else mentioned other CA vendors like RSA and Verisign. If you really want a manageable PKI that will give you appreciable increases in security, you should really look into a commercial PKI. Simple stuff, MS Cert Serv is fine, but for enterprise PKI, it fails.
Get an FM3 if you can. More expensive than an FM10, but it has aperture priority metering for snappys and when you loose batteries, it will still shoot from B to 1/4000. That's right, full shutter range with no juice. I couldn't be happier, especially on those -5f days outside.
Any ideas why this wasn't a problem?
Stick the moving parts outside the oil. But do you then have to worry about wicking the oil up the cables?
This is the book your looking for. Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000 (Pro-Developer) (Hardcover) That and technet. I have the 3rd edition and I found it very informative.
Back in the day, crypto was classified as munitions under ITAR.
Yeah, and it was actually easier to import strong crypto than export it, so alot of companies outside the US became very popular with the security vendors not only for the talentthat exists internationally, but also for the import capabiity.
Yeah, but that doesn't mean it has to be in production. Many mega corps like IBM, MS, HP, etc, are patent engines. They come up with cool ideas, build a prototype, and presto, the "new machine" requirements is compete!
Yeah, and that is especially a concern with all the DNS registrars. Can they be trusted to really identify that some one is who they say they are beyond taking the information off of a credit card statement?
But if your ISPs DNS has been poisoned, then the attacker can resolve any host to the IP address of thier choice. If I control your ISP DNS server and I tell it that www.amazon.com resolves to 192.168.10.1 which is a web server I control, then I can send you a certificate claiming to be from www.amazon.com, and the DNS name will match the FQDN in the certificate. That wouldn't be a problem.
You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place. But that is a different problem altogether.
SecDNS doens't address poor set-up. It attemtps to assert zone authority through record signing. Right now, you don't know if DNS is resolving the correct address or not which makes poisoning such a nasty threat.
.com zone before they begin to expire. Anyone know any different?
RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole
Just wait until those rascally hackers start taking pictures of a screen because the USB port is all gummed up. That'll learn ya!
You still don't know what application is sending requests, you only know what protocol it is speaking. But so what? sure it just looks like standard http/ssl traffic
The point about SSL is that the data is encrypted and an application layer firewall can't look into the payload. So I probably wasn't clear about why I reccomended an SSL Proxy. Try it this way. The SSL Proxy decrypts and re-encrypts traffic between the client and the server. Prior to passing the now unencrypted traffic to the other side, inspect it to make sure it is, in this case, valid HTTP traffic, versus, say, a terminal session encalsulated in SSL/TLS. If it is valid HTTP, you can also look for well-known mime-types to block certain types of traffic like file sharing, etc.
Your comments about "service level attacks" that break the protocol specification are out of place here too.
Ok, I was being clear about how "application level firewall" can be defined. In some cases, an application level firewall is really just a generic proxy that proxies TCP connection without regard to upper level protocols. Generic proxies thwart network level attacks (layer 3). Application level proxies that proxy service applications like HTTP, FTP, SSH, SMTP, POP3, IMAP regardless of the destination port 1) instantiate (partially or fully depending on the applicaiton layer firewall) the application service and 2) can enforce protocol conformance, block or allow methods, MIME types, and other protocol stuff. Examples of these types of firewalls are Secure Computing Sidewinder, Symantec EFS, and Cyberguard. Application level proxies can also be defined as proxies that make decisions based on data in the application payload like "don't allow SQL injection", "block XSS", and "make sure the XML is well formed and adheres to its DTD." Examples of these types of application level firewalls are Imperva, F5, and Teros.
What you are suggesting is not just difficult - it is impossible (for well designed malware).
Huh? Sure it is possible. Application proxies have been around for a long, long time. Secure Computing has one, as does Cyberguard, and Symantec. Now in thier cases, "application level" enforces the layer 7 and downward protocols for some services, not all. For example, they all have HTTP, FTP, SMTP, IMAP, and POP3 application level proxies. Some support Oracle's SQL*Net V1 or V2. Others support H.323 but not SIP. Anyway, service level attacks such as trying to overflow a buffer, generally will not work through application level proxies because service level attacks tend to violate the protocol specification (binary data where RFC-822 data should be) or violates sane behavior of the protocol, like a HTTP/1.1 host: header longer than 100 characters.
So your wondering about SSL? How about using an HTTP/SSL Proxy and forcing all outbound connections through the proxy and examining the underlying protocols prior to exiting a perimeter firewall? Let's face, the way SSL is used today doesn't provide that much protection anyway (hint: how do you know the certificate from amazon.com is valid? Because you have the public signing certificate from Verisign that was used to sign teh certificate from amazon.com? How did you get Verisign certificate and how do you know *it* is valid? More importantly, how do you know a malicious signing certificate hasn't been inserted into your supposed trusted certificate store? Sorry, that isn't the hint, it's the answer) so you you really don't loose much by using an SSL proxy.
What is more difficult, is application level firewalls that protect web applications (instantiated within the HTML, XML, etc flying back and forth) from malicious use like SQL injection, cooking and field tampering, and yes, buffer overflows. But it can be done.
Home Routers/Firewalls protect your machine against INBOUND, unsolicited connection requests.
That is not correct. Typical home routers are Network Address Port Translation (NAPT) devices that translate private internal addres to a singel public external address. Stopping unsolicited external connections is a beneficial side-effect of NAPT because there is no translation rule for the NAPT router to pass traffic inward. Now, many NAPT routers can't properly handle dynamic protocols like gaming protocoals (specirfically gaming protocols that use ephemeral ports from external hosts (VoIP suffers from this too, btw)), so without specific game support (on a per title or service basis), you essentially create a default inbound rule that says "any external unsolicted connection gets sent to this internal computer."
Software firewalls protect you against OUTBOUND connections you did not authorize.
Wrong again. Host firewalls will block unsolicted external connections to the host and in fact was the original design goal of BlackICE, Zone, and others. Check it out. Turn one on, scan it and see what happens. Then turn off the host firewall, scan it, and compare the results. The blocking of outbound connections came later, as a feature to stop worms and network viruses from spreading.
So if your doing on-line games and your router doesn't intelligently support the gaming protocol (assuming the gaming protocol uses ephemeral ports), then your host is a sitting duck.
So I just upped to 1.5 and Flash objects were not painting.
I have Adblock 0.5.2.039, the latest. So go into Extensions, Adblock, Options and uncheck Obj-Tabs.
Seems to get rid of the block tabs, otherwise it works fine.
erg. Google-analytics stopped working. Flash problem maybe?
I'm fairly sure that the sub-registrars you go through (godaddy.com, regsiter.com, etc.) are just middle men.
godaddy.com is not a sub-registrar, it is a registrar. One of many in fact.
I beleive in 1999, NSI had to allow external registrars to register domain names and compete on price.
MOD parent FUNNY!
Seriously, I know alot of lawyers that are also in IT in some fashion--programmer, net admin, etc. Being a lawyer who understands technology is great pairing of skills.
You are wrong on both counts and you are spreading FUD.
The global warming threat is far from confirmed. There is overwhelming evidence to the contrary. And there have been catastrophic events to the Internet (not including the AOL invasion (ok, karma whore cheap shot. Laugh, it's supposed to be funny)). Remember Slammer, Melissa, and a handful of other fast moving worms that took out large portions of the network for several hours at a time? That was pretty catastrpohic. However, let's also remember that those events were pretty much mitigated within a day or two.
About the only thing that is really going to threaten the "Internet" is taking out the NAPs.
SANS Top 20, November 22, 2005 is here.
This is the first year that they are pulling out specifically application and network devices/software. However, to anyone who reads Bugtraq, Full Disclosure, or VulnWatch, this is incredibly old news.
I suspect that the new attention is partly due to marketing and partly due to better tracking facilities by ISC.
Feed a server carefully crafted, malformed packets and it may behave in unpredictable ways. We show that several IPSec implementations of IKE V1 don't behave properly.
Not news kids, just development as usual.
Oh, and I like the bit about "possibly executing code." That, I believe, is FUD. Prove that you can execute code.
the whole freakin' point of a small business is that they don't do business in multiple states
Hi, there is thing new thing called the I-n-t-e-r-n-e-t. Maybe you have seen it. It's quite cool. I think it is owned by Microsoft. Or at least they invented it because they have that Explorer thing.
Anyway, you should check it out because, like, I can buy stuff across the world without even making a phone call!
Really, go check it out. Everyone is doing it.