My sources predict another 43,000 + attacks before the end of next year!
--Spence
Perhaps one company CAN 'own' a d-net:
on
Scour is Dead
·
· Score: 1
...or more precisely, be *used* by a d-net.
Why not use free "anonymous" web-based email services to pass messages and file data?
Imagine: you're running a d-net server, but you listen for connections with a Hotmail or Hushmail account. When you see connection requests from a known-safe peer (confirmed through public-key signatures on messages) you connect directly with the peer through IP. Otherwise, you service requests *slowly* through Hotmail messages.
Also, think about the PR nightmare waiting for an attacker (government or otherwise): they would need to investigate and monitor Hotmail accounts! End-users understand Hotmail, and some would feel violated if it were known that 'authorities' are monitoring their Hotmail accounts for filesharing activity.
I proposed this exact thing (with details) to the GnutellaDev and GnutellaNG mailing lists -- look for mailing list archive entries with something about protecting against content dilution.
GnutellaNG didn't think too much about it...probably because I rambled and didn't structure my very long email well at all. Most people probably didn't even read it...my own fault.
I have re-proposed the same idea to Blocks (another distributed filesharing system that is NOT Gnutella-like -- http://www.kripto.org/blocks) and we seem to be running with it. We're currently going to be making alpha testers go out and download GPG themselves, and a future version of the client will automatically find and verify cryptographic material out on the Blocks network.
Blocks is going to be different than Gnutella -- it'll require more bandwidth, more clueful users, and require the client to be connected for days at a time to really get the most benefit. But in tradeoff you get much more anonymity and deniability of content, and in the future you'll get true content verification -- no more wasted downloads.
--Michael Spencer
blocks@mspencer.net
Open Source or Open Commit Access?
on
Geek Flavor
·
· Score: 1
If you liken this website to the CVS repository of a project...bad things will happen to your source if you allow random visitors to change or delete files.
Is this an attempt to dilute the meaning of Open Source? Is this "Open Source" in the Al Gore sense? I think many of us consider the only requirement of an Open Source website to be making the source available (View Source) and accepting and implementing suggestions from the public.
I posted this a few days ago on the message board at http://gnutelladev.wego.com.
---BEGIN GnutellaDev post---
I agree that this is a serious problem, and I have a solution in mind. Unfortunately, it's probably a solution best implemented by GnutellaNG. I'll discuss it here though.
I believe what's needed is a distributed content- and host-verification system based on public-key cryptography signatures and a web-of-trust. (GPG sources could be used for the PK crypto) I don't really have a good response for the privacy concerns about plastering persistent identities all over the content out there...but that's just one of many things that need to be discussed.
For those unfamiliar with the distributed web-of-trust implemented in the original PGP release: the idea is that using public-key crypto (where the encryption key has two halves, a public- and a private- half, which are linked in a very special mathematical way...what you 'do' with one half requires the other half to 'undo') you can place signatures on things -- include a hash of the content, create a message using your private key which can be verified by your public key.
In the PGP world this is used to create a web-of-trust: if you have a key owned by a person you trust (say, your very technical neighbor John) you might trust two things about his key: you might or might not trust that his key will remained owned by him (trusting the identity of the key) and you might or might not trust the integrity of the owner in certifying other keys (trusting the integrity of signatures made by the key). So you could trust the key of a complete sociopath, merely saying that you know the key belongs to him personally...but you don't exactly trust his signatures on other peoples' keys. Or you could trust both the key and the signatures of your neighbor John -- not only do you believe his key belongs to him personally, but you believe that when he puts a signature on some third-party key out there, then that third-party key probably really belongs to that person.
In Gnutella, this could be used to maintain a distributed database of trusted individuals and servers (anonymity will be discussed later) and trusted content. The effect will be that, for a given user, once he's taken the time to tell Gnutella how accurate the songs he downloads are...these songs weren't what their filename claimed they were, while these other songs were accurate and of X quality...he can publish signatures affirming to other users that files with X length and Y CRC really do contain Q content. Another user who trusts his signature can then trust files signed by him.
In the simplest case, this system would consist of a separate database of content signatures. When you get a search result from the servlet you're interested in (which contains a filename, size, and CRC) you do another search (perhaps in another network altogether) to find signatures for that file and public keys to verify the signatures with. Each key represents an individual, and each signature represents a public certification made by that individual about that content. Without a web of trust, all I really get from this is a cryptographically strong way of tying identities to content certifications. I have no idea how trustworthy the identities are.
This simplest case can be easilly attacked -- I'll build onto it soon. Obviously, just as quickly as I can create signatures that certify good content as good and bad content as bad, the 'AIAA' (attacking Industry Artists Association) can create identities and signatures that certify good content as bad and bad content as good. So I've only gained ground if an arbitrary user can learn, either from a web page or IRC or whatever...that signatures made from my key are accurate and signatures made from other keys are always inaccurate. The target audience isn't going to want to find and add their own content certification keys.
A more realistic example would implement a web-of-trust. We now have key signatures as well as content signatures: in the keyring management section of my client, I can investigate the keys I know about, by searching for key signatures for the key in question. My which-keys-can-I-trust problem is still there, but easier to overcome now: if we have a few definitely-trusted keys (like the original authors of Gnutella, or known information freedom advocates), those keys can delegate trust to people by signing their keys. Big deviation from the PGP web of trust model here: in PGP you're merely certifying the ownership of the key when you issue a signature. How much you trust an individual is never published by PGP. In the system being discussed here, you are interested in trust more than identity, so you publish trust information. Trust is published by issuing a key signature certificate out into the network, and it's revoked by issuing a key signature revocation certificate.
A client can verify a given key's trustworthiness by the signature path from the known-and-trusted keys. If a key is signed directly by a known-and-trusted key, it's also pretty well trusted. If a key is signed by someone who is signed by someone who is...eventually signed by a trusted key, trust will be established, but with lower confidence. Most likely, the given key will have many many signatures with a fault-tolerant signature path leading back to the trusted keys. If we suppose that one of the original trusted keys' "trusted lieutenants" (keys signed directly by one of the original trusted keys) were to go bad and start signing AIAA keys and start certifying bad content, the original trusted key owner would revoke the trust granted to that individual. All keys signed by that individual would no-longer benefit from that individual's trust. That doesn't mean they become untrusted...but we should hope they have some trust-granting signatures other than derived from the bad individual...because the bad individual's signature is no-longer meaningful.
This model is more likely to survive attacks. Keys that create bad content signatures simply never get marked as trusted. Keys that were once trusted, but have now began creating bad content signatures and signing other bad keys, have their signatures revoked and are no-longer trusted.
This trust network can be self-starting, also. The client software should be able to catalog all of the content and key signatures made by a key. If a particular client can directly measure the 'decisions' made by a key -- checked that its files really are the way it claims they are, and checked that the other keys signed by this key seem to be trustworthy (ugh, recursion) that client can decide to trust that key (partially or completely), thus making another 'root' of the trust tree. To put it another way, the client could also compare the decisions 'influenced' by a key -- which content signatures would become trusted if that key was trusted -- and compare those content signatures to the overlapping content signatures made by the existing trusted network...the client could measure how trustworthy the key might be.
In practice, it seems silly to require processing several public-key crypto operations and finding and downloading many key certificates and files, to tell whether a given content file is worth downloading or not. However...we don't have to use Gnutella to transfer keys and signatures: I imagine Freenet might be more appropriate for this kind of content. (So yes, besides adding the GPG source to Gnutella, I'm proposing merging Gnutella with Freenet someday, using Freenet for key distribution.) Also, each client will need to keep a keyring, retaining the keys and signatures that pertain to the content it's downloaded and the keys it uses frequently.
Assuming a trust network that fans out quickly, with each influential key signing dozens of other keys instead of two or three, it may only require three or four dips into the distributed keyserver to verify content. The client could verify content in the background...coloring a search result's icon from red to yellow to green as it gets more of the key and certificate material it needs.
The only major concern left is privacy and anonymity. These keys are personal identities: for a key to be effective it must be maintained by one person. However, the key and the identity might not be obviously-related: the network won't expose where a key's signatures are entering the network from, and keyring files must be seized or stolen to confirm that any given identity belongs to a specific computer. In addition to that, these keys can be detached from their identities if the owner destroys his private key. The existing signatures made by that orphaned key still stand and are still meaningful, but nobody can tell what individual once owned that key.
It is probably not illegal to help maintain a web of trust. It's probably illegal to host the content directly, and it might be somewhat illegal to directly publish signatures that confirm that someone else's content is what it claims to be (affirming to the world that you personally downloaded the content and confirmed that it was good). However, it's probably not illegal to sign someone else's key, attributing trust to them. All you're really saying is that you trust them to sign only good content -- and you have no idea whether that content is legal or not.
In the Gnutella interface, this web-of-trust system would probably be seen as a key-management screen, a content-rating screen, and as trust levels displayed next to each search result. In the content-rating screen you could look at the content you have downloaded and rated (good/bad, or several more-specific ratings), and who has signed the content. In the key-management screen you could look at the keys you know about, what content the keys affect, and how your ratings compare with trusted or untrusted keys' ratings. When you get search results, a summary content rating can be displayed next to each search result. The system can calculate ratings either on-demand (right-click -> Investigate) or automatically (i.e. search results returned 50), and can explain and graph those ratings for you (I trusted this file because these people certified the file.)
This file represents a vision for the kinda-distant future...but it will be realized only if people get excited about it and work to implement it. If you personally don't understand part of the discussion presented here, or if I forgot to explain something, or if something doesn't make sense, please post here in the forum and/or email me at gnet-comments@mspencer.net.
Thanks for reading. This idea is *yours* now -- please do your part to help it become reality.
I just finished working with two FBI case agents out of Omaha Nebraska (*cough* SiliCorn Valley) regarding tracking down a UDP packet-storm DCA and a simple web site defacement of our 'honey-pot' machine.
Generally, the FBI is clueless only when you throw your hands up in the air and say "I've been hacked!" and expect them to do all the work. If you can do the major investigation yourself (looking up ISP's with 'dig -x ###.###.###.### soa' and 'whois ###.###.###.###@whois.arin.net' and of course 'whois domainname.com' and 'nslookup ###.###.###.###') and draw them a picture, they follow along and understand very well.
It was fun watching a tense meeting with two 'G-men' melt into laughing and joking. They seemed to understand the 'hacker scene' pretty well: the arms-race, the script-kiddies, and the major web sites you get exploits from. And they were visibly excited when they saw that I had done their footwork for them.
Even if the local FBI agents are somewhat clueless (which these weren't) they have someplace full of very clueful people who can analyze your logs for you. If you come across as knowledgable, they'll recommend you to the analysis people, and they'll work with you.
(And remember: When you're getting DCA'ed, 'tcpdump -n -i eth# | gzip > capture.log.gz' is very very useful evidence. When you get your upstream ISP to filter out the flood traffic, sometimes the originator of the attack will ping you to see how your connection is doing. Those little innocent probes in between major shifts in attack activity make for great evidence.)
Slashdot Mirror
Hmm...a port number is 16 bits...
65535 - 22,000...
My sources predict another 43,000 + attacks before the end of next year!
--Spence
...or more precisely, be *used* by a d-net.
Why not use free "anonymous" web-based email services to pass messages and file data?
Imagine: you're running a d-net server, but you listen for connections with a Hotmail or Hushmail account. When you see connection requests from a known-safe peer (confirmed through public-key signatures on messages) you connect directly with the peer through IP. Otherwise, you service requests *slowly* through Hotmail messages.
Also, think about the PR nightmare waiting for an attacker (government or otherwise): they would need to investigate and monitor Hotmail accounts! End-users understand Hotmail, and some would feel violated if it were known that 'authorities' are monitoring their Hotmail accounts for filesharing activity.
--Michael Spencer
blocks@mspencer.net
Yes, exactly!
I proposed this exact thing (with details) to the GnutellaDev and GnutellaNG mailing lists -- look for mailing list archive entries with something about protecting against content dilution.
GnutellaNG didn't think too much about it...probably because I rambled and didn't structure my very long email well at all. Most people probably didn't even read it...my own fault.
I have re-proposed the same idea to Blocks (another distributed filesharing system that is NOT Gnutella-like -- http://www.kripto.org/blocks) and we seem to be running with it. We're currently going to be making alpha testers go out and download GPG themselves, and a future version of the client will automatically find and verify cryptographic material out on the Blocks network.
Blocks is going to be different than Gnutella -- it'll require more bandwidth, more clueful users, and require the client to be connected for days at a time to really get the most benefit. But in tradeoff you get much more anonymity and deniability of content, and in the future you'll get true content verification -- no more wasted downloads.
--Michael Spencer
blocks@mspencer.net
If you liken this website to the CVS repository of a project...bad things will happen to your source if you allow random visitors to change or delete files.
Is this an attempt to dilute the meaning of Open Source? Is this "Open Source" in the Al Gore sense? I think many of us consider the only requirement of an Open Source website to be making the source available (View Source) and accepting and implementing suggestions from the public.
--Michael Spencer Jr.
spam@mspencer.net
I posted this a few days ago on the message board at http://gnutelladev.wego.com.
---BEGIN GnutellaDev post---
I agree that this is a serious problem, and I have a solution in mind. Unfortunately, it's probably a solution best implemented by GnutellaNG. I'll discuss it here though.
I believe what's needed is a distributed content- and host-verification system based on public-key cryptography signatures and a web-of-trust. (GPG sources could be used for the PK crypto) I don't really have a good response for the privacy concerns about plastering persistent identities all over the content out there...but that's just one of many things that need to be discussed.
For those unfamiliar with the distributed web-of-trust implemented in the original PGP release: the idea is that using public-key crypto (where the encryption key has two halves, a public- and a private- half, which are linked in a very special mathematical way...what you 'do' with one half requires the other half to 'undo') you can place signatures on things -- include a hash of the content, create a message using your private key which can be verified by your public key.
In the PGP world this is used to create a web-of-trust: if you have a key owned by a person you trust (say, your very technical neighbor John) you might trust two things about his key: you might or might not trust that his key will remained owned by him (trusting the identity of the key) and you might or might not trust the integrity of the owner in certifying other keys (trusting the integrity of signatures made by the key). So you could trust the key of a complete sociopath, merely saying that you know the key belongs to him personally...but you don't exactly trust his signatures on other peoples' keys. Or you could trust both the key and the signatures of your neighbor John -- not only do you believe his key belongs to him personally, but you believe that when he puts a signature on some third-party key out there, then that third-party key probably really belongs to that person.
In Gnutella, this could be used to maintain a distributed database of trusted individuals and servers (anonymity will be discussed later) and trusted content. The effect will be that, for a given user, once he's taken the time to tell Gnutella how accurate the songs he downloads are...these songs weren't what their filename claimed they were, while these other songs were accurate and of X quality...he can publish signatures affirming to other users that files with X length and Y CRC really do contain Q content. Another user who trusts his signature can then trust files signed by him.
In the simplest case, this system would consist of a separate database of content signatures. When you get a search result from the servlet you're interested in (which contains a filename, size, and CRC) you do another search (perhaps in another network altogether) to find signatures for that file and public keys to verify the signatures with. Each key represents an individual, and each signature represents a public certification made by that individual about that content. Without a web of trust, all I really get from this is a cryptographically strong way of tying identities to content certifications. I have no idea how trustworthy the identities are.
This simplest case can be easilly attacked -- I'll build onto it soon. Obviously, just as quickly as I can create signatures that certify good content as good and bad content as bad, the 'AIAA' (attacking Industry Artists Association) can create identities and signatures that certify good content as bad and bad content as good. So I've only gained ground if an arbitrary user can learn, either from a web page or IRC or whatever...that signatures made from my key are accurate and signatures made from other keys are always inaccurate. The target audience isn't going to want to find and add their own content certification keys.
A more realistic example would implement a web-of-trust. We now have key signatures as well as content signatures: in the keyring management section of my client, I can investigate the keys I know about, by searching for key signatures for the key in question. My which-keys-can-I-trust problem is still there, but easier to overcome now: if we have a few definitely-trusted keys (like the original authors of Gnutella, or known information freedom advocates), those keys can delegate trust to people by signing their keys. Big deviation from the PGP web of trust model here: in PGP you're merely certifying the ownership of the key when you issue a signature. How much you trust an individual is never published by PGP. In the system being discussed here, you are interested in trust more than identity, so you publish trust information. Trust is published by issuing a key signature certificate out into the network, and it's revoked by issuing a key signature revocation certificate.
A client can verify a given key's trustworthiness by the signature path from the known-and-trusted keys. If a key is signed directly by a known-and-trusted key, it's also pretty well trusted. If a key is signed by someone who is signed by someone who is...eventually signed by a trusted key, trust will be established, but with lower confidence. Most likely, the given key will have many many signatures with a fault-tolerant signature path leading back to the trusted keys. If we suppose that one of the original trusted keys' "trusted lieutenants" (keys signed directly by one of the original trusted keys) were to go bad and start signing AIAA keys and start certifying bad content, the original trusted key owner would revoke the trust granted to that individual. All keys signed by that individual would no-longer benefit from that individual's trust. That doesn't mean they become untrusted...but we should hope they have some trust-granting signatures other than derived from the bad individual...because the bad individual's signature is no-longer meaningful.
This model is more likely to survive attacks. Keys that create bad content signatures simply never get marked as trusted. Keys that were once trusted, but have now began creating bad content signatures and signing other bad keys, have their signatures revoked and are no-longer trusted.
This trust network can be self-starting, also. The client software should be able to catalog all of the content and key signatures made by a key. If a particular client can directly measure the 'decisions' made by a key -- checked that its files really are the way it claims they are, and checked that the other keys signed by this key seem to be trustworthy (ugh, recursion) that client can decide to trust that key (partially or completely), thus making another 'root' of the trust tree. To put it another way, the client could also compare the decisions 'influenced' by a key -- which content signatures would become trusted if that key was trusted -- and compare those content signatures to the overlapping content signatures made by the existing trusted network...the client could measure how trustworthy the key might be.
In practice, it seems silly to require processing several public-key crypto operations and finding and downloading many key certificates and files, to tell whether a given content file is worth downloading or not. However...we don't have to use Gnutella to transfer keys and signatures: I imagine Freenet might be more appropriate for this kind of content. (So yes, besides adding the GPG source to Gnutella, I'm proposing merging Gnutella with Freenet someday, using Freenet for key distribution.) Also, each client will need to keep a keyring, retaining the keys and signatures that pertain to the content it's downloaded and the keys it uses frequently.
Assuming a trust network that fans out quickly, with each influential key signing dozens of other keys instead of two or three, it may only require three or four dips into the distributed keyserver to verify content. The client could verify content in the background...coloring a search result's icon from red to yellow to green as it gets more of the key and certificate material it needs.
The only major concern left is privacy and anonymity. These keys are personal identities: for a key to be effective it must be maintained by one person. However, the key and the identity might not be obviously-related: the network won't expose where a key's signatures are entering the network from, and keyring files must be seized or stolen to confirm that any given identity belongs to a specific computer. In addition to that, these keys can be detached from their identities if the owner destroys his private key. The existing signatures made by that orphaned key still stand and are still meaningful, but nobody can tell what individual once owned that key.
It is probably not illegal to help maintain a web of trust. It's probably illegal to host the content directly, and it might be somewhat illegal to directly publish signatures that confirm that someone else's content is what it claims to be (affirming to the world that you personally downloaded the content and confirmed that it was good). However, it's probably not illegal to sign someone else's key, attributing trust to them. All you're really saying is that you trust them to sign only good content -- and you have no idea whether that content is legal or not.
In the Gnutella interface, this web-of-trust system would probably be seen as a key-management screen, a content-rating screen, and as trust levels displayed next to each search result. In the content-rating screen you could look at the content you have downloaded and rated (good/bad, or several more-specific ratings), and who has signed the content. In the key-management screen you could look at the keys you know about, what content the keys affect, and how your ratings compare with trusted or untrusted keys' ratings. When you get search results, a summary content rating can be displayed next to each search result. The system can calculate ratings either on-demand (right-click -> Investigate) or automatically (i.e. search results returned 50), and can explain and graph those ratings for you (I trusted this file because these people certified the file.)
This file represents a vision for the kinda-distant future...but it will be realized only if people get excited about it and work to implement it. If you personally don't understand part of the discussion presented here, or if I forgot to explain something, or if something doesn't make sense, please post here in the forum and/or email me at gnet-comments@mspencer.net.
Thanks for reading. This idea is *yours* now -- please do your part to help it become reality.
The FBI isn't always clueless.
I just finished working with two FBI case agents out of Omaha Nebraska (*cough* SiliCorn Valley) regarding tracking down a UDP packet-storm DCA and a simple web site defacement of our 'honey-pot' machine.
Generally, the FBI is clueless only when you throw your hands up in the air and say "I've been hacked!" and expect them to do all the work. If you can do the major investigation yourself (looking up ISP's with 'dig -x ###.###.###.### soa' and 'whois ###.###.###.###@whois.arin.net' and of course 'whois domainname.com' and 'nslookup ###.###.###.###') and draw them a picture, they follow along and understand very well.
It was fun watching a tense meeting with two 'G-men' melt into laughing and joking. They seemed to understand the 'hacker scene' pretty well: the arms-race, the script-kiddies, and the major web sites you get exploits from. And they were visibly excited when they saw that I had done their footwork for them.
Even if the local FBI agents are somewhat clueless (which these weren't) they have someplace full of very clueful people who can analyze your logs for you. If you come across as knowledgable, they'll recommend you to the analysis people, and they'll work with you.
(And remember: When you're getting DCA'ed, 'tcpdump -n -i eth# | gzip > capture.log.gz' is very very useful evidence. When you get your upstream ISP to filter out the flood traffic, sometimes the originator of the attack will ping you to see how your connection is doing. Those little innocent probes in between major shifts in attack activity make for great evidence.)