Re: Foiling MITM attacks on source and ports trees
On Fri, Jan 02, 2009 at 05:44:12PM +0100, cpghost wrote: Any idea? Could this be implemented as a plugin to Subversion (since it must access previous revisions of files and previously computed digests)? Given read-only access to the repository, a set of simple Python scripts or C/C++ programs could easily implement the basic functionality and cache the results for fast retrieval by other scripts. But how well will all this scale? Sorry to revive this thread by replying to self, but nothing has materialized out of it (yet). Considering all that has been said up until now, it boils down to this: Issue #1 was signing the list: With or without SSL/TLS certificates, the (compressed) list could be signed by a web-trusted GnuPG Project Key, so let's assume it will be, and deal with the issue of transmission over SSL and how to get a certificate for the server(s) later (if at all). Issue #2 was how to generate the list out of the repository. A script that has (read-only) access to the Subversion repo would first in batch mode compute md5/sha256 checksums for *all* revisions available. It may take some time, but so what? It's only a one-time job, so let it run overnight to checksum the few GBs. The results could be stored in an arbitrary database. Then, another script will have to be hooked into Subversion, so that each commit will have that script compute the md5/sha256 checksums of the additional revisions, and store them in the database as well. This doesn't seem too much of a burden on the server, because even if the commits come in bursts, the number of bytes to commit are very fast checksummed... and saved in the database (I think / hope). It doesn't look like an overly expensive operation. Issue #3 was how to generate the list on-demand. That's a simple database query script, that would select a subset of files, revisions and checksums from the database, compress the result, sign it with the GnuPG Project Key, and return it to the user. This scales well to many concurrent client queries, because the database is independent from the Subversion server and can run on separate hardware -- and even be replicated if need be. Issue #4 was how to get the checksums on the client side. A simple app could connect to the checksum server (the app defined in Issue #3) -- or one of its mirrors if need be -- and select a signed list for a specific subrange (say, now up to 24h in the past). It would verify the signature using the public Project Key (obtained through a secure channel -- but let's care about that later when the infrastructure is in place). This app could factor out the tasks of querying the server and checking the signature into a library, that could also be used by an expanded version of csup. The idea is that csup, called with a special flag would verify the checksums of all files downloaded in the current run; while the main app could still check the integrity of a tree fetched 2 months ago, provided it is called with the right time stamp. Issue #5 was how to identify the revisions of files stored locally. That's a tough one, AFAICS. How to solve that one? Ideas? On old trees, its kinda hopeless (but read below); new invocations of a modified csup could save metadata, including revisions numbers somewhere (/var/db/sup perhaps), and use those metadata. For old(er) trees, checksums could be computed locally and sent to the checksum server for identification purposes. The server could match the path and checksums obtained through the client, and return a revision number (if any) out of the database. That in turn could be stored post-facto in /var/db/sup, and everything could proceed as above. Soo... implementation should now be easy as pie and require just a few lines of Python or a few more lines of C and a couple of little programs... and of course read-only access to the repository for deployment once it's ready. Or is it not yet? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Wed, Jan 07, 2009 at 08:37:37AM +, Matthew Seaman wrote: You're kind of stuck then aren't you -- at least in respect TLS/SSL and x509 certificates? If you don't trust any of the bodies who have the capability to authenticate the owners of a particular cryptographic key/certificate on your behalf, then you're going to have to do that authentication yourself. Which is cool if you happen to know the movers and shakers in the FreeBSD world personally and you can sit down with them and compare key fingerprints. Or even if you can get an introduction to them through a mutual acquaintance. Not exactly. See my comments up the thread a bit about alternative site/cert agreement verification. All the certifying authority *really* does for you is offer out-of-band verification that the cert that has been delivered to you does indeed belong with the IP address that delivered it. It obviously doesn't actually do that worth a damn, though, as the evidence of Verisign's (among others) continued use of MD5 shows. Multiply corroborated independent sources prove a far more trustworthy verifier in the aggregate, in my opinion, than commercial entities operating on an authentication model that amounts to an appeal to authority fallacy. If you think Verisign certification proves anything about the character of the person who bought the cert in the first place, you might want to rethink that -- even if you assume an incompetent Verisign employee hasn't accidentally sabotaged the authentication process this time. Authentication of an entity and the decision whether to trust that entity are two separate things, and should be treated as such. -- Chad Perrin [ content licensed OWL: http://owl.apotheon.org ] Quoth Anonymous C Professor: To work on a program with the compiler in debug mode and then to sell it compiling it without the debug option is like learning to swim with floaters and then taking them off to swim across the Atlantic. pgp5SSdmd6gF2.pgp Description: PGP signature
Re: Foiling MITM attacks on source and ports trees
On Tue, Jan 06, 2009 at 09:08:56PM -0800, Walt Pawley wrote: At 12:31 PM -0700 1/6/09, Chad Perrin wrote: On the other hand, I don't trust Verisign, either. What's to trust? If you pay them, you in. Exactly. That's why I -- as the guy sitting in front of the *browser* -- don't trust Verisign to do my authentication and authorization thinking for me. There's at minimum a potential for conflict of interest there, in addition to the likelihood (now realized, in the form of leveraging MD5 to crack Verisign cert authenticity) of bureaucratic incompetence producing disaster entirely by accident. -- Chad Perrin [ content licensed OWL: http://owl.apotheon.org ] Quoth James Madison: If Tyranny and Oppression come to this land, it will be in the guise of fighting a foreign enemy. pgpRVzc9D763z.pgp Description: PGP signature
Re: Foiling MITM attacks on source and ports trees
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Chad Perrin wrote: | On Tue, Jan 06, 2009 at 11:11:52AM -0900, Mel wrote: | On Tuesday 06 January 2009 10:31:26 Chad Perrin wrote: | Out-of-band corroboration of a certificate's authenticity is kind of | necessary to the security model of SSL/TLS. A self-signed certificate, | in and of itself, is not really sufficient to ensure the absence of a man | in the middle attack or other compromise of the system. | | On the other hand, I don't trust Verisign, either. | In the less virtual world, we only trust governments to provide identity | papers (manufactured by companies, but still the records are kept and | verified by a government entity). | Instead of trying to regulate the internet and provide a penal system, | governments would do much better taking their responsibility on these issues. | It shouldn't be so hard to give every citizen the option to get an online | certificate corresponding with their passport and similarly for Chambers of | Commerce to provide certificates for businesses. | | My distrust of of the certifying authority is not mitigated by replacing | Verisign with FedCorp. Institutional incompetence is typically a result | of bureaucracy -- and even major corporations don't get as mired in | bureaucracy as government. | You're kind of stuck then aren't you -- at least in respect TLS/SSL and x509 certificates? If you don't trust any of the bodies who have the capability to authenticate the owners of a particular cryptographic key/certificate on your behalf, then you're going to have to do that authentication yourself. Which is cool if you happen to know the movers and shakers in the FreeBSD world personally and you can sit down with them and compare key fingerprints. Or even if you can get an introduction to them through a mutual acquaintance. Oh, wait -- I seem to have reinvented the PGP web-of-trust thing. Shame there's nothing quite like it for x509 certificates. The free Thawte service for signing S/MIME certs for individual e-mail users is about the closest, but Thawte is just a wholly owned subsidiary of Verisign, and they going to be stongly motivated not to internally compete with their profitable business of selling expensive web server certificates. Even so, while PGP signatures work well between a normal circle of correspondents, I can't see how they could work practically to authenticate a service designed to be open to the general public. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAklkadAACgkQ8Mjk52CukIzhfQCfVGxx8HBGH/bvWG4VOowDVcTe /78AnR1gDCiA+1kb2agWKC99H54ImW4T =YVhl -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
Unless designed carefully, there will be substantial logistical problems to maintaining such lists of signatures. ... You can then verify the correctness of what's on your disk ... The idea is that one needs to get this public key only once ... IMHO, this could or should take place at the subversion server itself. This problem has already been solved in the form of Git*. Now whether FreeBSD can/will migrate to Git or an equivalent for version control is another question. The security benefits would result even if a trusted person (the FreeBSD security team, maybe?) maintained a git mirror of the CVS/Subversion/Whatever repository. Git avoids the issue of versioned lists of signatures by simply making the version history of the repository an unbroken chain. If any link in history is changed, the sha1 checksums no longer compute. By simply verifying a sha1 hash, you can be assured (at least, as assured as [that implementation of] sha1 can make you feel) that the files at that point in time and all their prior history are exactly the same on your computer as what's on the distribution server. No lengthy lists or checksum tuples are required. The checksums are built in to the version control itself. Git also provides a mechanism for cryptographic sign-off of tags, which would provide the public/private keyed infrastructure you're trying to (awkwardly) replicate with SSL and PKI. The combination of sha1-strength history integrity verification and cryptographic tags mean all the information necessary to validate your on-disk source tree (and its history) is widely available and easily verified even if obtained from an untrusted source. You will need a secure means of obtaining either a (single) sha1 hash or a public key, but everything else can e verified once you have that small bit of very public (and therefore difficult to forge) information. Even if Git isn't the answer, it's at least worth stealing some of their ideas. * http://git.or.cz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
someone like the FreeBSD Foundation as an appropriate body to own the cert. OT I would actually trust a self-signed cert by the FreeBSD security officer, more then one by Verisign. of course. there is no need to have an authority to make key pairs, everybody do it alone. actually i would fear using such keys because i'm sure such companies do have a copy of both keys. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Tue, Jan 06, 2009 at 10:22:29AM +0100, Wojciech Puchar wrote: someone like the FreeBSD Foundation as an appropriate body to own the cert. OT I would actually trust a self-signed cert by the FreeBSD security officer, more then one by Verisign. of course. there is no need to have an authority to make key pairs, everybody do it alone. actually i would fear using such keys because i'm sure such companies do have a copy of both keys. Out-of-band corroboration of a certificate's authenticity is kind of necessary to the security model of SSL/TLS. A self-signed certificate, in and of itself, is not really sufficient to ensure the absence of a man in the middle attack or other compromise of the system. On the other hand, I don't trust Verisign, either. I believe some steps are being made by the Perpsectives [1] project that lead in the right direction [2]. Unfortunately, it's not available at present for FreeBSD, because the Firefox plugin depends on a binary executable compiled from C, and my (brief) discussion with one of the people involved in the project about the potential of porting it to FreeBSD didn't really bear fruit. NOTES: [1] http://www.cs.cmu.edu/~perspectives/index.html [2] http://blogs.techrepublic.com.com/security/?p#571 -- Chad Perrin [ content licensed OWL: http://owl.apotheon.org ] Quoth Anonymous: Why do we never have time to do it right, but always have time to do it over? pgpdWFBWpraoO.pgp Description: PGP signature
Re: Foiling MITM attacks on source and ports trees
On Tuesday 06 January 2009 10:31:26 Chad Perrin wrote: On Tue, Jan 06, 2009 at 10:22:29AM +0100, Wojciech Puchar wrote: someone like the FreeBSD Foundation as an appropriate body to own the cert. OT I would actually trust a self-signed cert by the FreeBSD security officer, more then one by Verisign. of course. there is no need to have an authority to make key pairs, everybody do it alone. actually i would fear using such keys because i'm sure such companies do have a copy of both keys. Out-of-band corroboration of a certificate's authenticity is kind of necessary to the security model of SSL/TLS. A self-signed certificate, in and of itself, is not really sufficient to ensure the absence of a man in the middle attack or other compromise of the system. On the other hand, I don't trust Verisign, either. In the less virtual world, we only trust governments to provide identity papers (manufactured by companies, but still the records are kept and verified by a government entity). Instead of trying to regulate the internet and provide a penal system, governments would do much better taking their responsibility on these issues. It shouldn't be so hard to give every citizen the option to get an online certificate corresponding with their passport and similarly for Chambers of Commerce to provide certificates for businesses. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
Hi, It shouldn't be so hard to give every citizen the option to get an online certificate corresponding with their passport and similarly for Chambers of Commerce to provide certificates for businesses. Only that would mean that 200 countries become Certificate Authorities and tens of thousand of Chamber of Commerce become too. Would you be ready to trust some very remote Chamber of Commerce of some thrid world country to be a a thrustworthy CA? Not to mention that to manage these so many CA, you need an infrastructure that is yet to be deployed. Best, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
OT: The future of CA's (Was: Re: Foiling MITM attacks on source and ports trees)
On Tuesday 06 January 2009 17:56:43 Olivier Nicole wrote: Hi, It shouldn't be so hard to give every citizen the option to get an online certificate corresponding with their passport and similarly for Chambers of Commerce to provide certificates for businesses. Only that would mean that 200 countries become Certificate Authorities and tens of thousand of Chamber of Commerce become too. Would you be ready to trust some very remote Chamber of Commerce of some thrid world country to be a a thrustworthy CA? About the same ammount as I trust their Chamber of Commerce registration. Remember that certs are used establish a trust relationship ultimately leading to a legally binding sale/purchase agreement. If I don't trust the Chamber of Commerce of the country in question, I certainly don't have a reason to do business with that company. In fact, having a 3rd party obscure the origin of the company is misleading, as in case of conflict, what exactly are your rights and how would they be resolved? Is this company even allowed to do business under this name/with these products, etc etc. Not to mention that to manage these so many CA, you need an infrastructure that is yet to be deployed. Actually, the infrastructure is already there. District governments already have an infrastructure to verify the identity of a person. Companies like Verisign had to implement this seperately. The thing that's missing is that governments do not see their responsibility. Yes, I do realize that the newly created CA's would have to be added to the list of trusted CA's for SSL clients. In a transitional period, this could be done backwards compatible by temporarily chaining to a root CA that's already known. Perhaps this technology even needs to be revisited as the potential list can outgrow the intent of the current scheme. However, I don't consider this a bad thing(tm). If there's one thing the internet has shown is that adoption of new technology can be near instantanious (Bittorrent, iTunes, email, IM to name a few). -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
At 12:31 PM -0700 1/6/09, Chad Perrin wrote: On the other hand, I don't trust Verisign, either. What's to trust? If you pay them, you in. -- Walter M. Pawley w...@wump.org Wump Research Company 676 River Bend Road, Roseburg, OR 97471 541-672-8975 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Tue, Jan 06, 2009 at 11:11:52AM -0900, Mel wrote: On Tuesday 06 January 2009 10:31:26 Chad Perrin wrote: Out-of-band corroboration of a certificate's authenticity is kind of necessary to the security model of SSL/TLS. A self-signed certificate, in and of itself, is not really sufficient to ensure the absence of a man in the middle attack or other compromise of the system. On the other hand, I don't trust Verisign, either. In the less virtual world, we only trust governments to provide identity papers (manufactured by companies, but still the records are kept and verified by a government entity). Instead of trying to regulate the internet and provide a penal system, governments would do much better taking their responsibility on these issues. It shouldn't be so hard to give every citizen the option to get an online certificate corresponding with their passport and similarly for Chambers of Commerce to provide certificates for businesses. My distrust of of the certifying authority is not mitigated by replacing Verisign with FedCorp. Institutional incompetence is typically a result of bureaucracy -- and even major corporations don't get as mired in bureaucracy as government. -- Chad Perrin [ content licensed OWL: http://owl.apotheon.org ] Quoth Bill McKibben: The laws of Congress and the laws of physics have grown increasingly divergent, and the laws of physics are not likely to yield. pgp20VPV43pmz.pgp Description: PGP signature
Re: Foiling MITM attacks on source and ports trees
On Saturday 03 January 2009 03:45:11 Matthew Seaman wrote: [*] Buying a high security cert from the likes of Verisign or OpenSRS would set you back about £800 p.a. and it would probably be necessary to use someone like the FreeBSD Foundation as an appropriate body to own the cert. OT I would actually trust a self-signed cert by the FreeBSD security officer, more then one by Verisign. Power hungry companies like Verisign are more succeptable to corruption then the entity I want to have or already a relationship with in the first place. /OT -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
RW wrote: On Fri, 02 Jan 2009 17:30:12 + Vincent Hoffman vi...@unsane.co.uk wrote: Admittedly this doesn't give a file by file checksum That's not really a problem, it's no easier to create a collision in a .gz file than a patch file. The more substantial weakness is that the key is verified against a hash stored on the original installation media. If someone went to the trouble of diverting dns or routing to create a fake FreeBSD site they would presumably make it self-consistent down to the ISO checksums. Yes. Anyone can generate checksums. The standard method of getting round this problem is to cryptographically sign the (lists of) checksums using some form of public/private key pair. Unless designed carefully, there will be substantial logistical problems to maintaining such lists of signatures. The least laborious mechanism I can think of would be this: an SSL secured web site using a key+cert signed by a trusted CA[*]. This site would have privileged access to the master repositories and would run a fairly simple CGI where supplying the location of a file from a checked out copy of a repo, plus version number information and whatever else is necessary to uniquely identify the specific file in question would be answered with a list of checksums (MD5, SHA1, SHA265 etc.) of that file. Obviously, this will require substantial caching of previously calculated checksums simply for performance. As an end user, you check out sources etc. from whatever of the mirrors is most suitable. You can then verify the correctness of what's on your disk by comparing a locally generated checksum with what you can download via a trusted channel from the checksum server. Since the checksum server is only accessible via HTTPS and has a trusted certificate it should not be possible to spoof. Traffic levels should be relatively small compared to the main distribution channels. Even so, because of the SSL requirement it's going to take a substantial piece of kit to provide this checksumming service at a decent performance level, especially when there are recent new releases. Cheers, Matthew [*] Buying a high security cert from the likes of Verisign or OpenSRS would set you back about £800 p.a. and it would probably be necessary to use someone like the FreeBSD Foundation as an appropriate body to own the cert. -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Foiling MITM attacks on source and ports trees
On Sat, Jan 03, 2009 at 01:38:25AM +, RW wrote: On Fri, 02 Jan 2009 17:30:12 + Vincent Hoffman vi...@unsane.co.uk wrote: Admittedly this doesn't give a file by file checksum That's not really a problem, it's no easier to create a collision in a .gz file than a patch file. The more substantial weakness is that the key is verified against a hash stored on the original installation media. If someone went to the trouble of diverting dns or routing to create a fake FreeBSD site they would presumably make it self-consistent down to the ISO checksums. That's why I suggested that the list of checksums be digitally signed by a private key belonging to The FreeBSD Project. It is assumed that getting the corresponding public key would be possible by other means not susceptible to MITM attacks (e.g. through endless replication all over the net, fingerprint in books etc...). -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Sat, Jan 03, 2009 at 12:45:11PM +, Matthew Seaman wrote: RW wrote: On Fri, 02 Jan 2009 17:30:12 + Vincent Hoffman vi...@unsane.co.uk wrote: Admittedly this doesn't give a file by file checksum That's not really a problem, it's no easier to create a collision in a .gz file than a patch file. The more substantial weakness is that the key is verified against a hash stored on the original installation media. If someone went to the trouble of diverting dns or routing to create a fake FreeBSD site they would presumably make it self-consistent down to the ISO checksums. Yes. Anyone can generate checksums. The standard method of getting round this problem is to cryptographically sign the (lists of) checksums using some form of public/private key pair. Right. Unless designed carefully, there will be substantial logistical problems to maintaining such lists of signatures. The least laborious mechanism I can think of would be this: an SSL secured web site using a key+cert signed by a trusted CA[*]. This site would have privileged access to the master repositories and would run a fairly simple CGI where supplying the location of a file from a checked out copy of a repo, plus version number information and whatever else is necessary to uniquely identify the specific file in question would be answered with a list of checksums (MD5, SHA1, SHA265 etc.) of that file. Actually, one only needs SSL to access a site that distributes the public key used for signing the lists of checksums. If this key is widely distributed, we could even do without an SSL certificate (though having one would be good, if the FreeBSD Foundation could pay for one). Obviously, this will require substantial caching of previously calculated checksums simply for performance. Already suggested. ;) As an end user, you check out sources etc. from whatever of the mirrors is most suitable. You can then verify the correctness of what's on your disk by comparing a locally generated checksum with what you can download via a trusted channel from the checksum server. Since the checksum server is only accessible via HTTPS and has a trusted certificate it should not be possible to spoof. Exactly. That's the basic idea. But even if we didn't have a trusted connection to the checksum server, the lists of checkums could still be digitally signed, and everyone who obtained the widely-known public key through a non-MITMed channel could still verify the integrity of this list. The idea is that one needs to get this public key only once from a secure channel, and could use it forever (or as long as it is valid and not revoked) to verify the signature of the checksum lists (which could themselves be distributed via non-trusted channels. Traffic levels should be relatively small compared to the main distribution channels. Even so, because of the SSL requirement it's going to take a substantial piece of kit to provide this checksumming service at a decent performance level, especially when there are recent new releases. IMHO, this could or should take place at the subversion server itself. Every commit should trigger an event, and the event handler would compute a set of checksums on-the-fly and store them in the backend. This shouldn't really be any CPU burden on the server itself (how many megabytes are committed per second? per hour? ... that need to be checksummed? Not so many I guess). The kit needed would be an extra server (the checksum queries server), that would connect to the repository -- or to the database that contains the cached checksums -- and reply to client queries such as: Gimme a list of checksums for this-and-this-subtree starting at timestamp N and ending at timestamp N+24h (or perhaps just: starting at timestamp N and defaulting to the inteval [N, N+24h] to avoid denial of service attacks by too broad interval queries) This server would then query the database or backend, and simply assemble a list of checksums, compress it, digitally sign the result with the Project's key, and send the binary stream back to the client. The client would verify the signature it got from the checksum queries server with the public key it obtained through secure channel, unpack the list, and compare the local checksums with the checksums on the list. Cheers, Matthew [*] Buying a high security cert from the likes of Verisign or OpenSRS would set you back about ?800 p.a. and it would probably be necessary to use someone like the FreeBSD Foundation as an appropriate body to own the cert. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Sat, 3 Jan 2009 19:46:59 +0100 cpghost cpgh...@cordula.ws wrote: On Sat, Jan 03, 2009 at 01:38:25AM +, RW wrote: On Fri, 02 Jan 2009 17:30:12 + Vincent Hoffman vi...@unsane.co.uk wrote: Admittedly this doesn't give a file by file checksum That's not really a problem, it's no easier to create a collision in a .gz file than a patch file. The more substantial weakness is that the key is verified against a hash stored on the original installation media. If someone went to the trouble of diverting dns or routing to create a fake FreeBSD site they would presumably make it self-consistent down to the ISO checksums. That's why I suggested that the list of checksums be digitally signed by a private key belonging to The FreeBSD Project. It is assumed that getting the corresponding public key would be possible by other means not susceptible to MITM attacks (e.g. through endless replication all over the net, fingerprint in books etc...). My point is that having signed updates etc (which is essentially what freebsd-update and portsnap do) is undermined if the original iso is not obtained securely. Currently that appears to be the weakest link. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
cpghost wrote:
Hello,
with MITM attacks [1] on the rise, I'm concerned about the integrity
of local /usr/src, /usr/doc, and /usr/ports trees fetched through csup
(and portsnap) from master or mirror servers.
[1] http://en.wikipedia.org/wiki/Man-in-the-middle_attack
There's already a small protection against MITM on the distfiles in
ports: distinfo contain md5 and sha256 digests. This is an excellent
idea that could be extended to *all* files in /usr/src, /usr/doc, and
/usr/ports.
According to http://www.daemonology.net (the creator of portsnap and
also freebsd-update as well as being the freebsd security officer's
website) and a quick look though the freebsd-update and portsnap
scripts, both portsnap and freebsd update provide reasonable
cryptographic protection from MITHM attacks.
({freebsd-update,portsnap}.conf contains a sha256 hash of the rsa key
used to sign the updates)
Admittedly this doesn't give a file by file checksum but does give
reasonable protection against MITM attacks for updates of the ports tree
and the -RELEASE src trees.
Vince
What I'd like to have is a way to check the fetched /usr/src,
/usr/doc, and /usr/ports files against a *digitally signed* list of
(file, revision, digest) tuples that would be generated on-the-fly and
on-demand, so that any modification of the files in transit would be
detected (provided the checker program runs on an uncompromised host,
of course).
This should not only apply to up-to-the-minute current files, but also
to files fetched, say, a few weeks or months ago (e.g. because they
are deployed in stable production servers).
Assuming there's a secure way (which is not affected by MITM) to
obtain a master public key (GnuPG key) of the FreeBSD Project, it
would be nice to have a mechanism in place that would:
Agreed, a more secure way of getting it than
http://www.freebsd.org/security/so_public_key.asc would be nice, (just
ssl would make me happy.)
1. create a compressed list of (file, revision, md5/sha1/...digest)
tuples for /usr/src, /usr/doc, and /usr/ports trees,
2. sign this list with the master private key of the project and
make it available.
Because the number of revisions for any specific file can be huge,
this list could grow very fast. It may be economical to have the
program create only (file, revision, digest) tuples for a limited
number of revisions, typically as many as needed between start and end
of a typical csup run on slow links, or at most, say, 24h... starting
at an arbitrary date in the past.
To save CPU cycles, previous computed (file, revision, digest)
tuples could be permanently cached in an RDBMS, in Subversion or
wherever else that's appropriate.
Oh, we could always use SSL between csup and the servers as fallback,
but SSL is not without flaws and I doubt that all mirrors would have
valid certificates, defeating the whole purpose of foiling MITM
attacks. And SSL alone doesn't permit checking after the fact
the integrity of an older snapshot.
Any idea? Could this be implemented as a plugin to Subversion (since
it must access previous revisions of files and previously computed
digests)? Given read-only access to the repository, a set of simple
Python scripts or C/C++ programs could easily implement the basic
functionality and cache the results for fast retrieval by other
scripts. But how well will all this scale?
Thanks,
-cpghost.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Fri, Jan 2, 2009 at 10:44 AM, cpghost cpgh...@cordula.ws wrote: Hello, with MITM attacks [1] on the rise, I'm concerned about the integrity of local /usr/src, /usr/doc, and /usr/ports trees fetched through csup (and portsnap) from master or mirror servers. [1] http://en.wikipedia.org/wiki/Man-in-the-middle_attack There's already a small protection against MITM on the distfiles in ports: distinfo contain md5 and sha256 digests. This is an excellent idea that could be extended to *all* files in /usr/src, /usr/doc, and /usr/ports. Something like this was discussed back in September: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026052.html I haven't tried Max's script yet, but it looks like it should do at least some of what you're looking for. Matt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Fri, Jan 02, 2009 at 11:26:45AM -0600, Matt wrote: On Fri, Jan 2, 2009 at 10:44 AM, cpghost cpgh...@cordula.ws wrote: Hello, with MITM attacks [1] on the rise, I'm concerned about the integrity of local /usr/src, /usr/doc, and /usr/ports trees fetched through csup (and portsnap) from master or mirror servers. [1] http://en.wikipedia.org/wiki/Man-in-the-middle_attack There's already a small protection against MITM on the distfiles in ports: distinfo contain md5 and sha256 digests. This is an excellent idea that could be extended to *all* files in /usr/src, /usr/doc, and /usr/ports. Something like this was discussed back in September: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026052.html I haven't tried Max's script yet, but it looks like it should do at least some of what you're looking for. It's a beginning for sure. I assume (403 error) Max generates and saves digests on his snapshots and the verification script does the same locally and simply compares both lists. In an extended version, it could grep for the digests in the increasingly big list on Max's site... But that's not ideal because: 1) There's no guarantee that Max's csup has not been MITM-ed itself. 2) Max can't csup EVERY revision to digest it in near real-time. 3) Even with SSL on his site, I'd prefer a digitally signed list. ;) With this version of the script, it's not possible to check the integrity of an arbitrary specific snapshot in time (say, starting with the subversion migration and later). That's why I'm thinking of (file, revision, digest) tuples, and not just (file, digest) tuples that would need to go in that list; and a logic to fetch a subset of the list, based on revision numbers. The main problem I see here with (file, digest) tuples, is how to guess the right revision number of the local file. Unless that is transferred alongside csup (into a metadata directory? /var/db/sup perhaps?), it will be necessary to check a local file against a list of known and good digests -- the list created from the repository out of all revisions that ever existed for that file --. This is good enough against casual MITM, where an attacker creates his own replacement files, but it's not good enough if the attacker merely substitutes a current file with an older (but legitimate) file that contains a vulnerability. That old file would verify OK because it has a valid digest, but it's still not the file that should be in the checkout. See the problem? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Fri, Jan 02, 2009 at 05:30:12PM +, Vincent Hoffman wrote:
cpghost wrote:
Hello,
with MITM attacks [1] on the rise, I'm concerned about the integrity
of local /usr/src, /usr/doc, and /usr/ports trees fetched through csup
(and portsnap) from master or mirror servers.
[1] http://en.wikipedia.org/wiki/Man-in-the-middle_attack
There's already a small protection against MITM on the distfiles in
ports: distinfo contain md5 and sha256 digests. This is an excellent
idea that could be extended to *all* files in /usr/src, /usr/doc, and
/usr/ports.
According to http://www.daemonology.net (the creator of portsnap and
also freebsd-update as well as being the freebsd security officer's
website) and a quick look though the freebsd-update and portsnap
scripts, both portsnap and freebsd update provide reasonable
cryptographic protection from MITHM attacks.
({freebsd-update,portsnap}.conf contains a sha256 hash of the rsa key
used to sign the updates)
Admittedly this doesn't give a file by file checksum but does give
reasonable protection against MITM attacks for updates of the ports tree
and the -RELEASE src trees.
Interesting! As csup user, I'm not using freebsd-update and portsnap
often nor regularly, but will have a look at it. Thanks for the hint.
Assuming there's a secure way (which is not affected by MITM) to
obtain a master public key (GnuPG key) of the FreeBSD Project, it
would be nice to have a mechanism in place that would:
Agreed, a more secure way of getting it than
http://www.freebsd.org/security/so_public_key.asc would be nice, (just
ssl would make me happy.)
Yup. ;)
Regards,
-cpghost.
--
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
It's a beginning for sure. I assume (403 error) Max generates and saves digests on his snapshots and the verification script does the same locally and simply compares both lists. it's plain paranoia. Yes such attacks are possible but usually there 100 other ways to compromise Your systems. if one really care then make your VPN for all your computers, use one that is unknown for others to download portsnap etc. and then use rsync to populate it to other machines. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Fri, Jan 02, 2009 at 08:04:10PM +0100, Wojciech Puchar wrote: It's a beginning for sure. I assume (403 error) Max generates and saves digests on his snapshots and the verification script does the same locally and simply compares both lists. it's plain paranoia. Yes such attacks are possible but usually there 100 other ways to compromise Your systems. if one really care then make your VPN for all your computers, use one that is unknown for others to download portsnap etc. and then use rsync to populate it to other machines. I'm already getting the files from one location and disseminate them via rsync-over-SSH-over-VPNs to the server farms. But the problem is the initial download from a cvsup mirror. That's the one I'm really concerned with. Note that I'm not concerned (all too much) with the integrity of the cvsup mirrors themselves (I trust cvsup server admins to take proper precautions against MITM between themselves and the master server, right guys?), but with the integrity of the TCP connection of random clients to those mirrors. That's the weakest link in the security chain, and I hope we can find a way to strenghten it. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
other ways to compromise Your systems. if one really care then make your VPN for all your computers, use one that is unknown for others to download portsnap etc. and then use rsync to populate it to other machines. I'm already getting the files from one location and disseminate them via rsync-over-SSH-over-VPNs to the server farms. But the problem is the initial download from a cvsup mirror. That's the one I'm really concerned with. just use widely-unknown computer like your private, even better - something that have dynamic IP :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Fri, Jan 02, 2009 at 10:53:29PM +0100, Wojciech Puchar wrote: other ways to compromise Your systems. if one really care then make your VPN for all your computers, use one that is unknown for others to download portsnap etc. and then use rsync to populate it to other machines. I'm already getting the files from one location and disseminate them via rsync-over-SSH-over-VPNs to the server farms. But the problem is the initial download from a cvsup mirror. That's the one I'm really concerned with. just use widely-unknown computer like your private, even better - something that have dynamic IP :) You wouldn't log in to your bank and rely on the assumption that your connection is NOT being actively monitored and that data could potentially be modified en-route. That's why such connections are always SSL-encoded, and why iTANs and other means are being used: the underlying TCP connection is ASSUMED to be insecure by default, and that is prudent to do. As an example: many UK users were surprised a little while ago to learn that their traffic was potentially being filtered by big transparent proxies, when some watchdog organisation required their ISPs to do so: http://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia If this is technically possible (and it is), then you want a way to know that the sources you've downloaded in your country ARE actually the sources that are on the mirror or master sites, and have not been modified on-the-fly by similar technology. This is important, really important, and not only for individuals, but also for companies that what to avoid industrial espionnage and some such. It's also vital for individuals in countries with repressive regimes that want to routinely spy on their Internet users. That's why signed trusted lists of digests are needed: basically, you can't rely on the ISPs NOT to interfere with your traffic (and it doesn't matter if they're compelled by law to do it, or if they or some interloper did it illegally). It's the matter of being confident that what you've downloaded was actually also what you've asked for. ;) -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
On Fri, 02 Jan 2009 17:30:12 + Vincent Hoffman vi...@unsane.co.uk wrote: Admittedly this doesn't give a file by file checksum That's not really a problem, it's no easier to create a collision in a .gz file than a patch file. The more substantial weakness is that the key is verified against a hash stored on the original installation media. If someone went to the trouble of diverting dns or routing to create a fake FreeBSD site they would presumably make it self-consistent down to the ISO checksums. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
