Re: Debian mirrors and MITM
On May 30, 2014, at 10:06 AM, micah anderson wrote: Kurt Roeckx k...@roeckx.be writes: On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? apt will check that the new apt is properly signed. This entire secure artifice depends entirely on the integrity of apt, and presumably the various libraries that it depends on. Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... micah I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. Using HTTPS for apt repos is a simple way to improve the security of all 4. It adds a weak backup security layer for #1, it makes it much more difficult for the attacker to do #2, #3, and #4. For those who want to find HTTPS mirrors, try my script here: https://guardianproject.info/2013/10/31/issues-when-distributing-software/ .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/476000fe-7a7d-4dab-b344-a928ef9e3...@at.or.at
Re: Debian mirrors and MITM
On Jun 2, 2014, at 9:29 AM, Jann Horn wrote: On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network Heh. Because SSL/TLS libraries are so impenetrable and secure? :D Even GnuPG has had exploitable bugs. Adding layers of different security techniques can help make the apt distribution system less fragile when such bugs inevitably arise. For example, if there was an exploitable bug in the GPG signing or checksum hash algorithms used by apt, anyone fetching packages over HTTP could have malicious versions inserted by systems like FOXACID. If HTTPS was in use, then that would required the attacker to modify the files on the servers where they are stored in order to use the initial GPG/hash exploit. So using HTTPS greatly reduces the attack surface. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/13319bed-07af-4cab-9969-8f8d663bc...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:05 AM, Hans-Christoph Steiner wrote: On May 30, 2014, at 10:06 AM, micah anderson wrote: Kurt Roeckx k...@roeckx.be writes: On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? apt will check that the new apt is properly signed. This entire secure artifice depends entirely on the integrity of apt, and presumably the various libraries that it depends on. Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... micah I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. Using HTTPS for apt repos is a simple way to improve the security of all 4. It adds a weak backup security layer for #1, it makes it much more difficult for the attacker to do #2, #3, and #4. For those who want to find HTTPS mirrors, try my script here: https://guardianproject.info/2013/10/31/issues-when-distributing-software/ .hc I should add: apt-transport-tor is a great project to improve this situation as well that is probably more secure than HTTPS, but at a cost of probably much slower download speeds. Using an apt mirror with an onion address would entirely supplant HTTPS. So don't get me wrong, I don't think HTTPS is a great system, what I'm saying is that the current state of apt mirrors (HTTP and GPG signing) is not enough. HTTPS can help, especially when used with some kind of certificate/SPKI pinning. Tor can help too, especially when used with onion addresses. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/578d5f80-c054-4d04-b1cd-39cebef3a...@at.or.at
Re: Debian mirrors and MITM
On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. HTTPS won't address #1 completely in the presence of mirrors, and debian doens't have the resources to serve all users without mirrors. It will not address #2. It may address #3, but less reliably than the current siutation. It may make #4 harder for certain scenarios, but not others (traffic analysis of specific host). Something like tor will be a better solution for #2, #4 while the current system provides #1 #3. (And also provides #2 for all practical purposes, given the length of the mirror list.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e4cb4f22-02c8-11e4-904c-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner h...@at.or.at wrote: On Jun 2, 2014, at 9:29 AM, Jann Horn wrote: On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network Heh. Because SSL/TLS libraries are so impenetrable and secure? :D Even GnuPG has had exploitable bugs. Adding layers of different security techniques can help make the apt distribution system less fragile when such bugs inevitably arise. Adding another layer of code does not always improve security. Using the argument of bugs, what happens when your vulnerable SSL clients connects to a malicious mirror? You suggest that GnuPG could have security flaws, but you promote software line that has already demonstrated numerous security problems. On a side, SSL is already available in apt, anyone is free to implement SSL on their mirror server and use it in their apt client. If you need to secure the initial installation download use the verification information found here https://www.debian.org/CD/verify. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/edd089f0-30e2-4946-8276-d3fa45696...@vianet.ca
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:55 AM, Reid Sutherland wrote: On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner h...@at.or.at wrote: On Jun 2, 2014, at 9:29 AM, Jann Horn wrote: On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network Heh. Because SSL/TLS libraries are so impenetrable and secure? :D Even GnuPG has had exploitable bugs. Adding layers of different security techniques can help make the apt distribution system less fragile when such bugs inevitably arise. Adding another layer of code does not always improve security. Using the argument of bugs, what happens when your vulnerable SSL clients connects to a malicious mirror? You suggest that GnuPG could have security flaws, but you promote software line that has already demonstrated numerous security problems. On a side, SSL is already available in apt, anyone is free to implement SSL on their mirror server and use it in their apt client. If you need to secure the initial installation download use the verification information found here https://www.debian.org/CD/verify. The point is to figure out a better way that is included by default. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/995ae110-08f9-47ff-9072-ade90c0bd...@at.or.at
Re: Debian mirrors and MITM
Hans-Christoph Steiner h...@at.or.at writes: I should add: apt-transport-tor is a great project to improve this situation as well that is probably more secure than HTTPS, but at a cost of probably much slower download speeds. Using an apt mirror with an onion address would entirely supplant HTTPS. So don't get me wrong, I don't think HTTPS is a great system, what I'm saying is that the current state of apt mirrors (HTTP and GPG signing) is not enough. HTTPS can help, especially when used with some kind of certificate/SPKI pinning. Tor can help too, especially when used with onion addresses. Are there any mirrors with a hidden service onion address? If so, I would like to know where! Are there any mirror operators out there who might be interested in adding a tor hidden service, but don't know how? If so, contact me, I'd be happy to help you set it up. micah pgpWPzlVCRj4v.pgp Description: PGP signature
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:52 AM, Michael Stone wrote: On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. HTTPS won't address #1 completely in the presence of mirrors, and debian doens't have the resources to serve all users without mirrors. It will not address #2. It may address #3, but less reliably than the current siutation. It may make #4 harder for certain scenarios, but not others (traffic analysis of specific host). Something like tor will be a better solution for #2, #4 while the current system provides #1 #3. (And also provides #2 for all practical purposes, given the length of the mirror list.) Mike Stone You are correct that HTTPS would not entirely address #2, but it does improve the situation over HTTP. For example, an ISP, network operator, or government could block an entire mirror or all mirrors by redirecting requests to their own mirror which does not get updates. That would be transparent to the user. This would make for a two week block on all updates (until the repo data expires). Using Using HTTPS and/or Tor with an onion address makes that a lot more difficult to do. Just connecting to an HTTP mirror via Tor would not prevent this. But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to the mirrors are blocked. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f3c70ec9-e2e9-48ca-87d9-7ce3f8296...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 12:10 PM, Hans-Christoph Steiner wrote: On Jul 3, 2014, at 11:52 AM, Michael Stone wrote: On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. HTTPS won't address #1 completely in the presence of mirrors, and debian doens't have the resources to serve all users without mirrors. It will not address #2. It may address #3, but less reliably than the current siutation. It may make #4 harder for certain scenarios, but not others (traffic analysis of specific host). Something like tor will be a better solution for #2, #4 while the current system provides #1 #3. (And also provides #2 for all practical purposes, given the length of the mirror list.) Mike Stone You are correct that HTTPS would not entirely address #2, but it does improve the situation over HTTP. For example, an ISP, network operator, or government could block an entire mirror or all mirrors by redirecting requests to their own mirror which does not get updates. That would be transparent to the user. This would make for a two week block on all updates (until the repo data expires). Using Using HTTPS and/or Tor with an onion address makes that a lot more difficult to do. Just connecting to an HTTP mirror via Tor would not prevent this. But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to the mirrors are blocked. .hc As for how to manage making HTTPS by default, this does not require every mirror buying HTTPS certificates every year from Certificate Authorities. There are workable solutions based on self-signed certificates. In Android apps, there are two approaches that are gaining traction: including certificate pins based on the Subject Public Key Info (SPKI) in an apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). And using Trust On First Use/Persistence of Pseudonym aka Memorizing Trust Manager (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a yes/no prompt the first time. These can also be optionally combined with the classic Certificate Authority, to provide a redundant check. We've been thinking about to make this workable, here are some notes: https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification Or there could be a password-based CA-replacement like http://tack.io .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cd4e3945-532a-4dad-9cfa-4742dfdcf...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner h...@at.or.at wrote: As for how to manage making HTTPS by default, this does not require every mirror buying HTTPS certificates every year from Certificate Authorities. There are workable solutions based on self-signed certificates. In Android apps, there are two approaches that are gaining traction: including certificate pins based on the Subject Public Key Info (SPKI) in an apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). And using Trust On First Use/Persistence of Pseudonym aka Memorizing Trust Manager (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a yes/no prompt the first time. These can also be optionally combined with the classic Certificate Authority, to provide a redundant check. We've been thinking about to make this workable, here are some notes: https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification Or there could be a password-based CA-replacement like http://tack.io Self-signed? Really? This is full of issues. Just because someone spends time on an idea, doesn’t mean it’s a good one. But this does trigger another idea; Debian could create their own CA for managing the project’s SSL infrastructure. Then we would just need to trust the Debian CA. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8eb7df12-c21b-4a86-a71e-79f4dc0e4...@vianet.ca
Re: Debian mirrors and MITM
On 07/03/2014 12:38 PM, Reid Sutherland wrote: On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner h...@at.or.at wrote: As for how to manage making HTTPS by default, this does not require every mirror buying HTTPS certificates every year from Certificate Authorities. There are workable solutions based on self-signed certificates. In Android apps, there are two approaches that are gaining traction: including certificate pins based on the Subject Public Key Info (SPKI) in an apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). And using Trust On First Use/Persistence of Pseudonym aka Memorizing Trust Manager (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a yes/no prompt the first time. These can also be optionally combined with the classic Certificate Authority, to provide a redundant check. We've been thinking about to make this workable, here are some notes: https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification Or there could be a password-based CA-replacement like http://tack.io Self-signed? Really? This is full of issues. Just because someone spends time on an idea, doesn’t mean it’s a good one. SSH uses entirely unsigned keys, and it has proven a lot more reliable than HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires signed keys, self-signed works. The signatures are only worth the trust path behind them, and CAs have not proven to be reliable trust paths. So if you can't rely on the signatures, why bother using them? This is not just my opinion, but of many others. Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. But this does trigger another idea; Debian could create their own CA for managing the project’s SSL infrastructure. Then we would just need to trust the Debian CA. That is also an option. That could also be done in parallel with what I proposed. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b588f5.7060...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner h...@at.or.at wrote: SSH uses entirely unsigned keys, and it has proven a lot more reliable than HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires signed keys, self-signed works. The signatures are only worth the trust path behind them, and CAs have not proven to be reliable trust paths. So if you can't rely on the signatures, why bother using them? This is not just my opinion, but of many others. Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. SSH is hand verified when you connect initially (thus creating a “signature”). Are you are going to hand-verify each signature / key? And then against what? Why not just verify the CD download once and be done with it? If you are paranoid, build a trust relationship with a mirror that provides SSL and save their cert. Anyway, I’m really over this. Have a good day. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3d3dc714-4833-47c3-89aa-d42b14d22...@vianet.ca
Re: Debian mirrors and MITM
On 07/03/2014 12:58 PM, Reid Sutherland wrote: On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner h...@at.or.at wrote: SSH uses entirely unsigned keys, and it has proven a lot more reliable than HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires signed keys, self-signed works. The signatures are only worth the trust path behind them, and CAs have not proven to be reliable trust paths. So if you can't rely on the signatures, why bother using them? This is not just my opinion, but of many others. Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. SSH is hand verified when you connect initially (thus creating a “signature”). That is not a crypto signature like on a TLS certificate or OpenPGP key. But I guess you could call writing the public key to ~/.ssh/known_hosts a signature of sorts. Are you are going to hand-verify each signature / key? And then against what? Why not just verify the CD download once and be done with it? If you are paranoid, build a trust relationship with a mirror that provides SSL and save their cert. Anyway, I’m really over this. Have a good day. I suggest you read the links that I included, they discuss these questions and more. Pinning means that the SPKI comes included in the software, like in the iso that you mention. In SSH speak, that would be like distributing an SSH known_hosts file along with the iso. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b58d10.1070...@at.or.at
Re: Debian mirrors and MITM
* Hans-Christoph Steiner h...@at.or.at [140703 18:10]: You are correct that HTTPS would not entirely address #2, but it does improve the situation over HTTP. For example, an ISP, network operator, or government could block an entire mirror or all mirrors by redirecting requests to their own mirror which does not get updates. That would be transparent to the user. - An ISP could just offer to host a mirror, thus getting the certificates for free. All you could avoid is getting in the way of someone willfully wasting bandwith by using a specific far away mirror. - A goverment could likely just do the same, but with any certificates/private keys of any mirrors near you. - It is only Transparent in a very abstract sense of the word. People know what security updates there are. Sending outdated stuff to many people is hard to hide. So you need a targeted attack, which would even cause more suspicion if someone realizes it. If someone updates the packages manually detection chances are astronomically high. If things are updated manually then a targeted attack might as well block the traffic and also block the mails going out about the automated update failing. And then there is still the massive negative aspect of using https, which any positive aspects have to trumph: If using https, people might actually think they can just use a browser or the like to download things and get a validated file. Which of course it is not, as so many people can trivially inject something. An false feeling of having security can be much worse than anything else often. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140703182620.ga2...@client.brlink.eu
Re: Debian mirrors and MITM
On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote: Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. Yes, and MS does similar. The difference is, they own their infrastructure and debian relies on donations. It's a lot harder for debian to control the certificates on third party machines than it is for a big company to control the certificates on its own machines. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/44a67e28-02e5-11e4-943d-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On 07/03/2014 03:08 PM, Michael Stone wrote: On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote: Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. Yes, and MS does similar. The difference is, they own their infrastructure and debian relies on donations. It's a lot harder for debian to control the certificates on third party machines than it is for a big company to control the certificates on its own machines. Mike Stone This is true. But Debian owns apt, and apt is the key piece of software that has to talk this encrypted protocol. It would be nice if it worked in the browser, but that is far from a requirement. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b5b070.1060...@at.or.at
Re: Debian mirrors and MITM
On 07/03/2014 02:26 PM, Bernhard R. Link wrote: * Hans-Christoph Steiner h...@at.or.at [140703 18:10]: You are correct that HTTPS would not entirely address #2, but it does improve the situation over HTTP. For example, an ISP, network operator, or government could block an entire mirror or all mirrors by redirecting requests to their own mirror which does not get updates. That would be transparent to the user. - An ISP could just offer to host a mirror, thus getting the certificates for free. All you could avoid is getting in the way of someone willfully wasting bandwith by using a specific far away mirror. - A goverment could likely just do the same, but with any certificates/private keys of any mirrors near you. Yes, there are definitely still possible attacks, even when using HTTPS+Tor onion address. I never said what I propose is perfect, just a large improvement. - It is only Transparent in a very abstract sense of the word. People know what security updates there are. Sending outdated stuff to many people is hard to hide. So you need a targeted attack, which would even cause more suspicion if someone realizes it. If someone updates the packages manually detection chances are astronomically high. If things are updated manually then a targeted attack might as well block the traffic and also block the mails going out about the automated update failing. In cases like the Great Firewall of China, they do country-wide things like this. They are quite good at blocking Tor all over China, for example. The vast majority of Debian/Ubuntu/etc. users only know there are updates because apt tells them so. And then there is still the massive negative aspect of using https, which any positive aspects have to trumph: If using https, people might actually think they can just use a browser or the like to download things and get a validated file. Which of course it is not, as so many people can trivially inject something. An false feeling of having security can be much worse than anything else often. Bernhard R. Link Yes, HTTPS should not be promoted as the thing that keeps the packages secure. That is the GPG signature. HTTPS mostly serves to obscure the traffic details from network observers. Many people think nothing of downloading and installing random software from an HTTP connection, so the bar is not currently very high. And there happens to be some concrete data on why this is important, it turns out that NSA/Five Eyes attempts to track everyone who lives outside the USA who searches for or downloads Tor: https://arstechnica.com/tech-policy/2014/07/report-rare-leaked-nsa-source-code-reveals-tor-servers-targeted/ .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b5b4f3.2030...@at.or.at
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network Heh. Because SSL/TLS libraries are so impenetrable and secure? :D signature.asc Description: Digital signature
Re: Debian mirrors and MITM
On Fri, 30 May 2014, Joey Hess wrote: Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. That doesn't buy you anything. Mirrors, even if you trusted them, don't use authenticated syncing protocols. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140531091020.gp20...@anguilla.noreply.org
Re: Debian mirrors and MITM
Peter Palfrader: On Fri, 30 May 2014, Joey Hess wrote: Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. That doesn't buy you anything. Mirrors, even if you trusted them, don't use authenticated syncing protocols. Looks like another issue worth fixing under the encrypt/authenticate all the things credo. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5389b3db.5020...@riseup.net
Re: Debian mirrors and MITM
Joey Hess: [...] there are situations where debootstrap is used without debian-archive-keyring being available, [...] Please elaborate, which situations are these? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5389b537.4020...@riseup.net
Re: Debian mirrors and MITM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 31-05-14 12:55, Patrick Schleizer wrote: Joey Hess: [...] there are situations where debootstrap is used without debian-archive-keyring being available, [...] Please elaborate, which situations are these? Let me answer this: using debootstrap on non-Debian systems, a scenario likely to become more frequent with Debian running in Linux containers (LXC). However, caveats apply in these scenarios, I will illustrate one way to think about this - if not just to gather feedback (it applies not only to LXC/VMs but in general for the case of spawning new Debian systems): 1) you have a Debian CD that you have verified being authentic thanks to your web of trust, this will be the system you trust most with trust level T0. Let's say you got it from the warm hands of your favourite DD and you are jealously storing it away as good wine 2) you are running a non-Debian system as host, let's say you have a trust level Tx on this operative system (it can be anything, but also Debian) 3) using debootstrap *without* a trust path to get the archive signing keys is enough of a mistake, in this case drinking the HTTPS cool-aid doesn't fix the trust path e.g. you would multiply Tx by zero (APT security != SSL CA security) 4) to overcome the problem above, you have to use your host system (with trust level Tx) to get the archive signing keys or to get an already seeded Debian chroot. I prefer the latter, thus I would download an official CD or net install ISO (verifiable thanks to https://www.debian.org/CD/verify), that we will label with trust level Ty 5) at this point you can continue the installation of your derived Debian system, that will have same trust level Ty Theorem: in absolutely no case you can create a system with a higher trust level than its parent: Tx = Ty Let's depict scenarios where you want to achieve Ty = T0. If at (3) you went forward without trusted archive signing keys, Ty is 0 (this covers the case Tx Ty), so let's drop this scenario. If your host system with trust Tx is let's say SuperSecureLinux downloaded from malwareland, then: Ty = T0 iif (if and only if) Tx = T0 (You must trust malwareland more than or equally as Debian) If instead your host system has trust level T0 (you installed it with that lovely CD), then chain of trust is respected (given that you followed [4] and not [3]): Tx = T0 = Ty = T0 Sorry for the pseudo logic, hope it adds positively to the understanding discussion. Related threads: https://lists.debian.org/debian-devel/2004/06/msg01499.html Kind regards, - -- Giuseppe Mazzotta -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTidwBAAoJEKWX1kB3NXekxNgIAIdCDjMnIN5i9EtuQsqMvbYG lFmmgpygoQZFcibptEJsoIYxsY6RK1XlcPh8F4SvOSa4EGDKa9PTF/9uHW/K0bpW fWpmJuMr2r04DadUp9mQe8hNDnNqeog6OavwjkZ7ruM1BldyZVWD1IAcGFb0b0B6 gnZW3/CuDDD2u7OWBVhan4Aru7WdXa/gqCNMhOe1YjKku4bOdx+DpsWKpVAtXgK0 iSMqwYk4x8rV80uWRvdD14ft3Dx9wX170l/rfN4q9/ut2gzqq/FPVs/RehURJSzD ZNP92nTrqt6yqRxLTNDZiV2HbBYjcMri8ACT3ycuNjLdKTEfwVHfq5OvszdV7oM= =PMc1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5389dc01.1050...@bitonic.nl
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bfad3c3a-e7f4-11e3-8753-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401453836.31698.123277245.0bfa1...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: What's stopping the attacker from serving a compromised apt? https://www.debian.org/CD/verify -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2169b45e-e7f9-11e3-851d-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 10:43 PM, Alfie John wrote: The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? Thinking about this more, If I wanted to target a Debian system via MITM, serving a compromised APT would be all I needed. In the future, a modified package could be served and it wouldn't matter what the signatures were seeing is I could have control of APT. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401454416.2074.123278697.7b672...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On 30/05/14 13:43, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? Oh god not this again. How exactly does using HTTPS solve this particular problem, anyway? If we assume a compromised APT then surely it can pass invalid SSL certificates as perfectly valid, too. It's not like sponsored attackers don't have access to all the SSL certificates they might ever want anyway. -- Chris Boot bo...@bootc.net -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53887e4b.90...@bootc.net
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 10:49 PM, Chris Boot wrote: The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? Oh god not this again. How exactly does using HTTPS solve this particular problem, anyway? If we assume a compromised APT then surely it can pass invalid SSL certificates as perfectly valid, too. It's not like sponsored attackers don't have access to all the SSL certificates they might ever want anyway. By mandating HTTPS, it would prevent QuantumInsert and FoxAcid being implemented during Debain installs and later package installs/updates. If you're worried about SSL certificates being compromised, going down the path of Debian self-signing its own certificate and distributed it via SneakerNet would be a way to prevent it. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401454841.3847.123280441.07217...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On 30/05/2014 8:52 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: What's stopping the attacker from serving a compromised apt? https://www.debian.org/CD/verify That will cover the installer, for the packages see: https://wiki.debian.org/SecureApt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53887f7a.2050...@shthead.com
Re: Debian mirrors and MITM
In Oct 2013 a similar discussion startet https://lists.debian.org/debian-security/2013/10/msg00027.html On 30. Mai 2014 14:15:01 MESZ, Alfie John alf...@fastmail.fm wrote: Hi guys, Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? Is there any compelling reason why the public Debian mirrors aren't served over HTTPS? If there isn't any, then further to this, is there any reason why not to mandate all public Debian mirrors HTTPS-only? Alfie -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5291f9a3-7d3a-46c2-a606-9eaff4ba4...@email.android.com
Re: Debian mirrors and MITM
On 2014-05-30 13:43, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? How would you get the client's system to install it in the first place? (More specifically, how would you get the cryptographic signature to match your package, given a lack of access to any of the keys trusted by the client's system?) There's something of a chicken and egg problem to your idea. Regards, Adam -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f78d4218bec9db44c0d491e4318f2...@mail.adsl.funky-badger.org
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? apt will check that the new apt is properly signed. During instalation there will be a package installed called debian-archive-keyring, and that is used to verify other things you download. So really the question is how you can be sure that the initial file that you downloaded are authentic and and contain the real key. And it depends on what you use as medium to do your installlation. For instance if you download a CD image, there are also files with the MD5/SHA1/SHA256. There is also a signed file there that you can use to verify that the hashes haven't been modified. So the question becomes if you have a trust path to who signed those files or not, which might not be the case for most people. Having this on a random website with HTTPS doesn't add anything to verify that the files you're downloading are the real ones or not, it doesn't give you an alternative trust path. That mirror might not have verified that the files haven't been tampered with, it might be compromised, it might be doing the attack itself. Having the mirrors do HTTPS doesn't solve your problem of having trust in the initial thing you download. So I basicly see 2 solutions: - The part that needs to be trusted needs to be downloaded over HTTPS from a debian.org host. I'm not sure cdimage.debian.org can offer HTTPS for everything. But maybe the files with the hashes alone can be enough? - Instead of using PGP to sign something we (also) use X509 certificates to sign something. But I don't know how easy it would be for people to actually verify that. Kurt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530131107.ga7...@roeckx.be
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:08 PM, Adam D. Barratt wrote: The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? How would you get the client's system to install it in the first place? (More specifically, how would you get the cryptographic signature to match your package, given a lack of access to any of the keys trusted by the client's system?) As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401455611.6597.123286253.5d5a4...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:03 PM, Estelmann, Christian wrote: In Oct 2013 a similar discussion startet https://lists.debian.org/debian-security/2013/10/msg00027.html Thanks for the link, but that discussion went nowhere pretty fast. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401455789.7468.123287497.4aee6...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On May 30, 2014, at 9:13 AM, Alfie John alf...@fastmail.fm wrote: On Fri, May 30, 2014, at 11:08 PM, Adam D. Barratt wrote: The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? How would you get the client's system to install it in the first place? (More specifically, how would you get the cryptographic signature to match your package, given a lack of access to any of the keys trusted by the client's system?) As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! So OpenSSL can be flawed and nobody bats an eye, APT uses GnuPG and everyone (this guy) loses their mind? Anyway, this is covered by GnuPG, unless it is flawed, we don’t have an issue. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d8754ebf-3f4d-4c90-a016-ccc195e33...@vianet.ca
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:17 PM, Reid Sutherland wrote: As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! So OpenSSL can be flawed and nobody bats an eye, APT uses GnuPG and everyone (this guy) loses their mind? Strawman much? What does bring up OpenSSL have anything to do with Debian mirrors being MITM? Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401456195.8866.123289337.07259...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:13:31PM +1000, Alfie John wrote: As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! That's why you verify the initial install media per the link I posted earlier... -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/90ebee24-e7fd-11e3-89ae-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 11:13:31PM +1000, Alfie John wrote: As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! That's why you verify the initial install media per the link I posted earlier... Well yes, that's something. But serving Debian over HTTPS would prevent the need for this. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401456358.9280.123291613.503b4...@webmail.messagingengine.com
Re: Debian mirrors and MITM
Yes, but I think this time it will not be better... Some (most?) mirrors are supporting https. If you want to use https just try which mirrors are supporting it. ftp.us.d.o will not work very good because of the DNS round robin. On 30. Mai 2014 15:16:29 MESZ, Alfie John alf...@fastmail.fm wrote: On Fri, May 30, 2014, at 11:03 PM, Estelmann, Christian wrote: In Oct 2013 a similar discussion startet https://lists.debian.org/debian-security/2013/10/msg00027.html Thanks for the link, but that discussion went nowhere pretty fast. Alfie -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c7a69a47-8ca7-4c4b-baaf-9ea1c4a25...@email.android.com
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote: That's why you verify the initial install media per the link I posted earlier... Oh, and those key fingerprints are on an https page for those who actually trust the CA system. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f2a5e71e-e7fd-11e3-bb9d-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:25:58PM +1000, Alfie John wrote: Well yes, that's something. But serving Debian over HTTPS would prevent the need for this. No, it wouldn't--you'd just have a different set of problems. Given that mirrors are distributed, it would probably be much more likely that you'd improperly rely on a compromised mirror simply because it's serving files via https. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1db1c630-e7fe-11e3-b616-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:27 PM, Michael Stone wrote: On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote: That's why you verify the initial install media per the link I posted earlier... Oh, and those key fingerprints are on an https page for those who actually trust the CA system. That was my next question. If the fingerprints are on a HTTPS served page, then yes that seems like a valid solution. And thanks Reid Sutherland for telling me I have no clue. Much appreciated. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401456637.10889.123292765.031db...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:29 PM, Michael Stone wrote: On Fri, May 30, 2014 at 11:25:58PM +1000, Alfie John wrote: Well yes, that's something. But serving Debian over HTTPS would prevent the need for this. No, it wouldn't--you'd just have a different set of problems. Given that mirrors are distributed, it would probably be much more likely that you'd improperly rely on a compromised mirror simply because it's serving files via https. If the fingerprints where on a canonical Debian server (aka non-mirror) being served over HTTPS, then I would be happy with that too. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401456752.11334.123293437.379eb...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On May 30, 2014, at 9:30 AM, Alfie John alf...@fastmail.fm wrote: On Fri, May 30, 2014, at 11:27 PM, Michael Stone wrote: On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote: That's why you verify the initial install media per the link I posted earlier... Oh, and those key fingerprints are on an https page for those who actually trust the CA system. That was my next question. If the fingerprints are on a HTTPS served page, then yes that seems like a valid solution. And thanks Reid Sutherland for telling me I have no clue. Much appreciated. In your private response to me, you didn’t. The whole point here is that Debian is already verifying the content it is receiving from any given data source. This was done from the very beginning because anyone can mirror and distribute Debian software. So unless there is a flaw with libc and libgpg, we are safe for downloading the public Debian content from anywhere. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f8cb8b56-fbf3-471d-9c06-94f03f05e...@vianet.ca
Re: Debian mirrors and MITM
On Fri, May 30, 2014, at 11:37 PM, Reid Sutherland wrote: Oh, and those key fingerprints are on an https page for those who actually trust the CA system. That was my next question. If the fingerprints are on a HTTPS served page, then yes that seems like a valid solution. And thanks Reid Sutherland for telling me I have no clue. Much appreciated. In your private response to me, you didn’t. The whole point here is that Debian is already verifying the content it is receiving from any given data source. This was done from the very beginning because anyone can mirror and distribute Debian software. So unless there is a flaw with libc and libgpg, we are safe for downloading the public Debian content from anywhere. Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401457832.14998.123299485.589aa...@webmail.messagingengine.com
Re: Debian mirrors and MITM
Kurt Roeckx k...@roeckx.be writes: On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? apt will check that the new apt is properly signed. This entire secure artifice depends entirely on the integrity of apt, and presumably the various libraries that it depends on. Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... micah pgp50ulNq1plS.pgp Description: PGP signature
Re: Debian mirrors and MITM
On May 30, 2014, at 9:50 AM, Alfie John alf...@fastmail.fm wrote: The whole point here is that Debian is already verifying the content it is receiving from any given data source. This was done from the very beginning because anyone can mirror and distribute Debian software. So unless there is a flaw with libc and libgpg, we are safe for downloading the public Debian content from anywhere. Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. I think you are on the right track, the MD5SUMS of each release does not seem to be available via SSL from debian.org. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e89fece8-7c01-45c3-9d7f-03919b612...@vianet.ca
Re: Debian mirrors and MITM
On Sat, May 31, 2014, at 12:06 AM, micah anderson wrote: The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? apt will check that the new apt is properly signed. This entire secure artifice depends entirely on the integrity of apt, and presumably the various libraries that it depends on. Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network Yep, already mentioned this one. This is my biggest issue. I'm beginning to this should be classified as a security bug in Debian. . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... It's only metadata, so who cares right? Only kidding. This is a totally legitimate scenario which I didn't think of. Nice. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401459088.20943.123308065.4e198...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote: Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. You were given a solution which is cryptographically sound and with a verifiable trust path, and you're rejecting it because you simply don't like it and would rather see a different solution with a weaker trust path. I'm not sure why you're continuing this argument. If you want to engage in a serious discussion about enhancing the current implementation or adding additional options, I'd suggest that you first study how the current implementation works, why it was implemented the way it was, the constraints inherent in the distributed mirror model, etc. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530141153.gb29...@mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote: Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. Alfie Hello. The thing is: When you download an .iso file, that .iso file also contains a signing key used to verify each package it downloads during the installation. Encryption is not important in this aspect, because what you are downloading is already publicly available and not secret. Everyone can download the same packages as the installer. Those are already public. The important bit is to verify that what you are downloading either manually, or via the installer, hasn't been tampered with. That is verification, and that is what is interesting here. The .iso file already contains a public key, and verifies every package it downloads along the way. You can disable that by hacking a bit in the installer, but it does requires an effort. For the next problem: Some mirror might theoretically have an .iso file which has been tampered with, but you should check the checksum for that file with what you find in the debian web-pages. If you download a .iso file via HTTP, it might have been tampered with, and if someone is intercepting your request for the public key, it might be changed. But i think that would be a problem anyways... -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530141605.GC17668@s1.t11.local
Re: Debian mirrors and MITM
On Sat, May 31, 2014 at 12:11:28AM +1000, Alfie John wrote: On Sat, May 31, 2014, at 12:06 AM, micah anderson wrote: . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... It's only metadata, so who cares right? Only kidding. This is a totally legitimate scenario which I didn't think of. Nice. So your solution to adding privacy is to make sure that every debian system checks in with debian directly rather than using a distributed infrastructure? I'd suggest looking at apt-transport-tor instead. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/68c76176-e807-11e3-91cf-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Sat, May 31, 2014 at 12:32:59AM +1000, Alfie John wrote: I'm definitely wanting to engage in serious discussion. I'm an avid Debian user and am wanting to protect its users. This *is* the Debian security mailing list after all right? All I was trying to do is ask questions as to why it is currently not being HTTPS-enforced and I got flamed for it. Well, you haven't shown any sign of having studied the publically available documentation or checked the public archives relating to the design decisions. Yes it's the debian-security mailing list, but that doesn't mean that it's scalable for debian to provide a personal walkthrough of the entire package signing architecture for everyone who sends an email to the list, does it? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d07185d6-e807-11e3-8a0e-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Sat, May 31, 2014, at 12:11 AM, Michael Stone wrote: On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote: Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. You were given a solution which is cryptographically sound and with a verifiable trust path, and you're rejecting it because you simply don't like it and would rather see a different solution with a weaker trust path. I'm not sure why you're continuing this argument. I'm not rejected it. I'm pretty happy with verifying packages via checksums hosted on a canonical Debian HTTPS site. My reaction was referring to Reid Sutherland's comments telling me in private that there was nothing to fear because there are smarter people in the room looking after everything. If you want to engage in a serious discussion about enhancing the current implementation or adding additional options, I'd suggest that you first study how the current implementation works, why it was implemented the way it was, the constraints inherent in the distributed mirror model, etc. I'm definitely wanting to engage in serious discussion. I'm an avid Debian user and am wanting to protect its users. This *is* the Debian security mailing list after all right? All I was trying to do is ask questions as to why it is currently not being HTTPS-enforced and I got flamed for it. I understand the issue of distributing to mirrors and then the problem of trusting each other, but that's another discussion entirely. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401460379.27062.123315561.30584...@webmail.messagingengine.com
Re: Debian mirrors and MITM
I have to laugh at this, my phone was going off constantly this morning, and I was thinking I don't have this much email normally! Looked over the discussion and thought, didn't this discussion happen recently? It was something I was randomly thinking about one day too, but really plain-text over http isn't really what's happening anyhow, and if you want to change it, change it to ftp transport, not many people trying to look there! (yes that bit is a joke, but still, I don't think HTTPS would really help a whole lot, except as someone else mentioned, you may be able to see the packages being installed without it.) On Fri, 2014-05-30 at 15:26 +0200, Estelmann, Christian wrote: Yes, but I think this time it will not be better... Some (most?) mirrors are supporting https. If you want to use https just try which mirrors are supporting it. ftp.us.d.o will not work very good because of the DNS round robin. On 30. Mai 2014 15:16:29 MESZ, Alfie John alf...@fastmail.fm wrote: On Fri, May 30, 2014, at 11:03 PM, Estelmann, Christian wrote: In Oct 2013 a similar discussion startet https://lists.debian.org/debian-security/2013/10/msg00027.html Thanks for the link, but that discussion went nowhere pretty fast. Alfie signature.asc Description: This is a digitally signed message part
Re: Debian mirrors and MITM
On May 30, 2014, at 10:11 AM, Alfie John alf...@fastmail.fm wrote: . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... It's only metadata, so who cares right? Only kidding. This is a totally legitimate scenario which I didn't think of. Nice. I don’t think it’s Debian's responsibility to protect the user from metadata snooping. Plus this adds complexity and excessive cost to distribution. If you want to partially solve this problem, mirror the entire repository (including security) to a private location. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fc595976-3fb8-485e-8cf3-eb697427f...@vianet.ca
Re: Debian mirrors and MITM
On Sat, May 31, 2014, at 12:39 AM, Michael Stone wrote: On Sat, May 31, 2014 at 12:32:59AM +1000, Alfie John wrote: I'm definitely wanting to engage in serious discussion. I'm an avid Debian user and am wanting to protect its users. This *is* the Debian security mailing list after all right? All I was trying to do is ask questions as to why it is currently not being HTTPS-enforced and I got flamed for it. Well, you haven't shown any sign of having studied the publically available documentation or checked the public archives relating to the design decisions. Yes it's the debian-security mailing list, but that doesn't mean that it's scalable for debian to provide a personal walkthrough of the entire package signing architecture for everyone who sends an email to the list, does it? I haven't read the docs. And you right, it's not a scalable solution. Sorry for asking questions. Alfie -- Alfie John alf...@fastmail.fm -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401461172.30245.123322097.6b61a...@webmail.messagingengine.com
Re: Debian mirrors and MITM
On Sat, May 31, 2014 at 12:46:12AM +1000, Alfie John wrote: Sorry for asking questions. Don't apologize for asking questions, it's perfectly reasonable to do so and you'll find that many people in debian are more than happy to answer questions. Just make sure that you put in enough effort yourself to ensure that you can actually engage constructively when you get an answer. (And if some of the answers point to documentation, make sure that you can't find the answers in the documentation.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/90cece00-e809-11e3-b232-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:03 AM, Hans Spaans h...@dailystuff.nl wrote: What basically is missing for a running system is repository signing key pinning for packages that would prevent that a third party repository could upgrade components provided by the base OS. How many of us didn't added debian-multimedia.org repositories and their PGP-keys to our systems in the past? How many of us didn't added some weird PPA? And who did remove remove both repo-lines AND PGP-keys when not needed anymore? And how many of those keys have proper rollover/revoke/maintenance procedure? Currently Debian checks if a package is signed by a trusted source, but not if the package is trusted for the package that you're going to update. Looks like a fun excise to offer a new apt package through the debian-multimedia infra for example and see who will notice. Or a modified openssh-server/client package through a populair PPA-repo. Thanks for bringing that issue! I feel the same way when I install a packet from a non-official PPA. It's definitely a problem of trust: I trust this PPA to install (say) firefox beta but I don't trust it enough to replace openssh. In this case you could think that pinning openss-server on the official repository would make the work but since the PPA could also rewrite a library used by openssh-server, it could inject code into it easily without alarming anyone (who cares when a PPA updates libfreebl ?). To protect openssh-server you would need to prevent modification of its dependency. But the PPA could just install a program that overrides the openssh-server manually (without doing that from APT). In this case, unless you run debsums you wouldn't notice it. In the end, the PPA can do pretty much whatever it wants from your system and this is scary. This is a hard problem to protect against and the only protection I see is... only install PPAs you can trust. -- Jérémie MARGUERIE -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caks89grgnv6yj2qakyduxxrk97ka6rhwsfbh2dexu81ebm+...@mail.gmail.com
Re: Debian mirrors and MITM
On 30.05.2014 21:35, Jeremie Marguerie wrote: To protect openssh-server you would need to prevent modification of its dependency. But the PPA could just install a program that overrides the openssh-server manually (without doing that from APT). In this case, unless you run debsums you wouldn't notice it. Any package can do whatever it wants, for example, in postinst script which is run as root. Unless every piece of software from PPA is totaly sandboxed somehow, loopholes are inevitable if arbitrary code should be run during installation/upgrade/removal. -- Denis Nikolaenko -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5388c850.1040...@nikolaenko.ru
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:35:58AM -0700, Jeremie Marguerie wrote: In the end, the PPA can do pretty much whatever it wants from your system and this is scary. This is a hard problem to protect against and the only protection I see is... only install PPAs you can trust. Yup; any pinning mechanism you add could be removed by a trusted malicious package. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/240fd966-e828-11e3-9f93-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. -- see shy jo signature.asc Description: Digital signature
Re: Debian mirrors and MITM
Le 30/05/2014 21:30, Joey Hess a écrit : Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. Note that at least debian.org DNS is segned by DNSSEC and DANE is used, which allows to check that the certificate used by a debian.org site is the real one. signature.asc Description: OpenPGP digital signature
Re: Debian mirrors and MITM
On Fri, 30 May 2014, Erwan David wrote: Le 30/05/2014 21:30, Joey Hess a écrit : Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. Note that at least debian.org DNS is segned by DNSSEC and DANE is used, which allows to check that the certificate used by a debian.org site is the real one. We don't ship a DNSSEC-enabled resolver by default, and fixing THAT would require some very careful considerations and large-scale testing. That said, AFAIC it is a critical bug on debootstrap that it doesn't just keel over and die very loudly when run without a trust path to verify the downloaded packages [as usual, this means we'd need to make it possible to provide such trust paths for the harder usecases as well]. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530200202.ga4...@khazad-dum.debian.net
Re: Debian mirrors and MITM
Le 30/05/2014 22:02, Henrique de Moraes Holschuh a écrit : On Fri, 30 May 2014, Erwan David wrote: Le 30/05/2014 21:30, Joey Hess a écrit : Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. Note that at least debian.org DNS is segned by DNSSEC and DANE is used, which allows to check that the certificate used by a debian.org site is the real one. We don't ship a DNSSEC-enabled resolver by default, and fixing THAT would require some very careful considerations and large-scale testing. That said, AFAIC it is a critical bug on debootstrap that it doesn't just keel over and die very loudly when run without a trust path to verify the downloaded packages [as usual, this means we'd need to make it possible to provide such trust paths for the harder usecases as well]. I understand it is not so simple... However it is a first step toward a more secure path. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5388e670.9070...@rail.eu.org
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 09:43:47PM +0200, Erwan David wrote: Note that at least debian.org DNS is segned by DNSSEC and DANE is used, which allows to check that the certificate used by a debian.org site is the real one. We're not at the point where that can be relied on in the real world. There are still resolvers that filter out DNSSEC records. (Sad, but true.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8bcb9ec8-e84b-11e3-9d19-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 8:15 PM, Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list Then you aren't trying hard enough, several of them support https, these ones at least: https://mirrors.kernel.org/debian/ https://mirrors.xmission.com/debian/ https://mirrors.ocf.berkeley.edu/debian/ https://mirrors.bloomu.edu/debian/ https://mirror.hmc.edu/debian/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FEZWZKx1dLf=R977L1a81bxToUUMB-=k_as+ndiud...@mail.gmail.com
