Re: dnssec-trigger + GNOME + NetworkManager integration
Michael Catanzaro wrote: On Fri, 2015-07-03 at 11:21 -0400, Mike Pinkerton wrote: Isn't the whole point to eliminate the need for third party certificate authorities entirely? Well I think you could choose to do that, or you could choose to use it as an additional security measure on top of traditional certificate authorities. Just to clarify what you are saying -- if there is a third party certificate chain which fails, then you would distrust the site. But if there is no third party certificate authority chain, and DANE succeeds, then you would accept the DANE-provided certificate and trust the site. I was thinking to require both to work, instead of just one or the other. Seems like that would make life hardest for the attacker. I've been hoping that DANE could get us closer to the goal of encrypting everything by lowering the barrier to using HTTPS. If anyone who has a domain can manage their own crypto keys, then they can enable HTTPS on all of their virtual hosts, test servers, temporary websites and whatnot both cheaper and easier than if they have to buy certificates from a CA. These advantages disappear if browsers will require CA signatures even in the presence of valid TLSA records. Before DANE there were three possible cases: C0: self-signed, that is not signed by a CA C-: presents a CA signature but verification fails C+: signed by a CA and verification succeeds DANE adds a second dimension and we get a matrix of nine possible cases: C0D0: not signed by a CA; has no TLSA records C0D-: not signed by a CA; has TLSA records but verification fails C0D+: not signed by a CA; has TLSA records and verification succeeds C-D0: presents a CA signature but verification fails; has no TLSA records C-D-: presents a CA signature but verification fails; has TLSA records but verification fails C-D+: presents a CA signature but verification fails; has TLSA records and verification succeeds C+D0: signed by a CA and verification succeeds; has no TLSA records C+D-: signed by a CA and verification succeeds; has TLSA records but verification fails C+D+: signed by a CA and verification succeeds; has TLSA records and verification succeeds When you write require both to work it sounds like you would accept only case C+D+. That would mean that you would start rejecting C+D0, denying your users access to all current HTTPS sites that don't use DANE yet, so that's probably not what you mean. All of the C- and D- cases are of course highly suspect and should be rejected, but both C0D+ and C+D0 should be accepted in my opinion. C0D+ is the case that removes people's excuses for not using HTTPS, and seems to be what certificate usage 3 in RFC 6698 is intended for. CAs would still serve a purpose. They could continue to provide big websites with extended validation certificates that allow browsers to assure the user that the website belongs to a particular company or other entity, whereas DANE only ties the public key to the domain name. Maybe some time in the distant future, when DNSsec is nearly ubiquitous, browsers can start rejecting case C+D0 to give the last few stragglers the push they need to start using DANE. Björn Persson pgpHTpfr0uGJA.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Michael Catanzaro wrote: I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). I have been in situations where I had to switch to hotspot sign-on mode and keep it that way for an extended time. For example, a few months ago when I did some work in a customer's office I found that I couldn't look up their internal servers. They had an internal DNS view, but their DNS servers were in rather bad shape and my Fedora was bypassing them. DNS administration wasn't what I was there to do, and starting by expanding my job seemed like a bad idea. I needed to get my job done, so my workaround was to use the hotspot sign-on mode the whole time I was there. But I'm a programmer who knows a lot about Internet protocols. I agree that the users that Gnome 3 targets won't be able to make informed decisions about DNSsec. For them the solution is to complain until the sysadmins fix the broken DNS servers. (When it turns out that they can access everything except the internal servers, then that will hopefully be a hint that there is a problem with the local domain.) If Gnome 3 has no option to disable validation, but the current DNSsec-trigger applet remains available and discoverable to people like me, then that's fine with me. Björn Persson pgpnoe3dBypHp.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 10 Jul 2015, at 15:40, Björn Persson wrote: Michael Catanzaro wrote: On Fri, 2015-07-03 at 11:21 -0400, Mike Pinkerton wrote: Isn't the whole point to eliminate the need for third party certificate authorities entirely? Well I think you could choose to do that, or you could choose to use it as an additional security measure on top of traditional certificate authorities. Just to clarify what you are saying -- if there is a third party certificate chain which fails, then you would distrust the site. But if there is no third party certificate authority chain, and DANE succeeds, then you would accept the DANE-provided certificate and trust the site. I was thinking to require both to work, instead of just one or the other. Seems like that would make life hardest for the attacker. [snip] DANE adds a second dimension and we get a matrix of nine possible cases: C0D0: not signed by a CA; has no TLSA records C0D-: not signed by a CA; has TLSA records but verification fails C0D+: not signed by a CA; has TLSA records and verification succeeds C-D0: presents a CA signature but verification fails; has no TLSA records C-D-: presents a CA signature but verification fails; has TLSA records but verification fails C-D+: presents a CA signature but verification fails; has TLSA records and verification succeeds C+D0: signed by a CA and verification succeeds; has no TLSA records C+D-: signed by a CA and verification succeeds; has TLSA records but verification fails C+D+: signed by a CA and verification succeeds; has TLSA records and verification succeeds When you write require both to work it sounds like you would accept only case C+D+. That would mean that you would start rejecting C+D0, denying your users access to all current HTTPS sites that don't use DANE yet, so that's probably not what you mean. All of the C- and D- cases are of course highly suspect and should be rejected, but both C0D+ and C+D0 should be accepted in my opinion. C0D+ is the case that removes people's excuses for not using HTTPS, and seems to be what certificate usage 3 in RFC 6698 is intended for. CAs would still serve a purpose. They could continue to provide big websites with extended validation certificates that allow browsers to assure the user that the website belongs to a particular company or other entity, whereas DANE only ties the public key to the domain name. Maybe some time in the distant future, when DNSsec is nearly ubiquitous, browsers can start rejecting case C+D0 to give the last few stragglers the push they need to start using DANE. I generally agree, except that I see the CAs eventually becoming a legacy artifact, with DANE enabling domains to take control of their own security directly without the mediation of third parties. So I see C+D+ as a transitional step between our current largely C+D0 state and a future C0D+ state. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 2.7.2015 17:56, Michael Catanzaro wrote: On Thu, 2015-07-02 at 16:38 +0200, Reindl Harald wrote: this type of attitude? everybody who reads IT news over the past years about CA's issued certificates even for Google knows that a CA signed certificate does not prove anything - the real problem is wehn this happens for Google somebody takes notice and the press writes about it if the same happens for your domain nobody will recognize it The situation is going to be getting a lot better in the near future, though. We're getting to the point where we can start enforcing Google's certificate transparency: if your certificate isn't on the public audit list, we can simply reject it. That allows individual web sites to get an immediate heads-up whenever any fraudulent certificate is issued for their site. (And researchers will be looking after the most important sites, of course.) That's not going to fix TLS in itself, because most sites probably don't care, but if the site does care, it will be impossible to issue a browser-trusted certificate for the site without that site knowing. (At least, that's my understanding of the technology; I haven't researched it thoroughly.) You're right that OCSP is worthless. GNOME applications don't currently perform any certificate revocation; I'm not willing to implement OCSP unless Firefox is willing to enforce it, and they aren't. We should implement OneCRL, which solves the revocation problem for intermediate certificates, but there doesn't seem to be any reasonable solution for individual sites yet. OCSP must-staple seems promising. Of course, we can't have any of these nice features in GNOME unless somebody wants to pay for their implementation. (If so, get in touch please.) For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 3 Jul 2015, at 10:44, Michael Catanzaro wrote: On Fri, 2015-07-03 at 15:43 +0200, Petr Spacek wrote: For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. I was planning to use DANE as a second required check in addition to the normal certificate chain. That is, if either the certificate chain doesn't check out or DANE fails, then something is spooky and the site should be inaccessible. Other browsers are throwing around ideas about using DANE to make the site accessible in the event the certificate chain fails, which seems like the wrong direction to me. I haven't really seen any good arguments in favor of one approach or the other, though. Isn't the whole point to eliminate the need for third party certificate authorities entirely? Just to clarify what you are saying -- if there is a third party certificate chain which fails, then you would distrust the site. But if there is no third party certificate authority chain, and DANE succeeds, then you would accept the DANE-provided certificate and trust the site. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Fri, 2015-07-03 at 15:43 +0200, Petr Spacek wrote: For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. I was planning to use DANE as a second required check in addition to the normal certificate chain. That is, if either the certificate chain doesn't check out or DANE fails, then something is spooky and the site should be inaccessible. Other browsers are throwing around ideas about using DANE to make the site accessible in the event the certificate chain fails, which seems like the wrong direction to me. I haven't really seen any good arguments in favor of one approach or the other, though. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
And dnssec-validator.cx for a Firefox/chrome plugin that you can see in action against fedoraproject.org that already deploys this Sent from my iPhone On Jul 3, 2015, at 10:43, Petr Spacek pspa...@redhat.com wrote: On 2.7.2015 17:56, Michael Catanzaro wrote: On Thu, 2015-07-02 at 16:38 +0200, Reindl Harald wrote: this type of attitude? everybody who reads IT news over the past years about CA's issued certificates even for Google knows that a CA signed certificate does not prove anything - the real problem is wehn this happens for Google somebody takes notice and the press writes about it if the same happens for your domain nobody will recognize it The situation is going to be getting a lot better in the near future, though. We're getting to the point where we can start enforcing Google's certificate transparency: if your certificate isn't on the public audit list, we can simply reject it. That allows individual web sites to get an immediate heads-up whenever any fraudulent certificate is issued for their site. (And researchers will be looking after the most important sites, of course.) That's not going to fix TLS in itself, because most sites probably don't care, but if the site does care, it will be impossible to issue a browser-trusted certificate for the site without that site knowing. (At least, that's my understanding of the technology; I haven't researched it thoroughly.) You're right that OCSP is worthless. GNOME applications don't currently perform any certificate revocation; I'm not willing to implement OCSP unless Firefox is willing to enforce it, and they aren't. We should implement OneCRL, which solves the revocation problem for intermediate certificates, but there doesn't seem to be any reasonable solution for individual sites yet. OCSP must-staple seems promising. Of course, we can't have any of these nice features in GNOME unless somebody wants to pay for their implementation. (If so, get in touch please.) For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Fri, 2015-07-03 at 11:21 -0400, Mike Pinkerton wrote: Isn't the whole point to eliminate the need for third party certificate authorities entirely? Well I think you could choose to do that, or you could choose to use it as an additional security measure on top of traditional certificate authorities. Just to clarify what you are saying -- if there is a third party certificate chain which fails, then you would distrust the site. But if there is no third party certificate authority chain, and DANE succeeds, then you would accept the DANE-provided certificate and trust the site. I was thinking to require both to work, instead of just one or the other. Seems like that would make life hardest for the attacker. Anyway, we'll probably wait for some major browser to use DANE first (probably won't be Chrome [1]) and then copy what they do for GNOME. Michael [1] https://www.imperialviolet.org/2015/01/17/notdane.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, Jul 2, 2015 at 2:33 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Browsers do show those warnings for self signed certs for a reason and that reason is *not* to sell certificates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, Jul 02, 2015 at 04:04:37PM +0200, drago01 wrote: a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Harald's point is that the trusted CAs are so numerous and so out of control that it's really hard to ascribe more trust to many of them than to a self-signed cert, yet there's no warning for these. You could theoretically inspect the cert manually and track down the issuer and so on, but I don't think very many people at all really do that. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 16:04 schrieb drago01: On Thu, Jul 2, 2015 at 2:33 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Browsers do show those warnings for self signed certs for a reason and that reason is *not* to sell certificates *lol* and with a CA certificate you can? given that there are thousands of CA's and you need *only one* with a broken verfication process to get a certificate for whatever you want you can't and if you would read IT news you would know that the CA system is broken by design signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - snip *lol* and with a CA certificate you can? A lot of us are sick of this type of attitude on fedora-devel, to the point where we don't actually care what you think anymore. Take this as an opportunity to read instead of jumping at people's throat with an attitude that wouldn't be tolerated in any other setting. /the silent majority -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 16:33 schrieb Bastien Nocera: - Original Message - snip *lol* and with a CA certificate you can? A lot of us are sick of this type of attitude on fedora-devel, to the point where we don't actually care what you think anymore. Take this as an opportunity to read instead of jumping at people's throat with an attitude that wouldn't be tolerated in any other setting. /the silent majority this type of attitude? everybody who reads IT news over the past years about CA's issued certificates even for Google knows that a CA signed certificate does not prove anything - the real problem is wehn this happens for Google somebody takes notice and the press writes about it if the same happens for your domain nobody will recognize it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 16:16 schrieb Reindl Harald: Am 02.07.2015 um 16:04 schrieb drago01: On Thu, Jul 2, 2015 at 2:33 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Browsers do show those warnings for self signed certs for a reason and that reason is *not* to sell certificates *lol* and with a CA certificate you can? given that there are thousands of CA's and you need *only one* with a broken verfication process to get a certificate for whatever you want you can't and if you would read IT news you would know that the CA system is broken by design and for can't really revoke it anymore: please inform yourself and you know that you in reality can't revoke a cert because all the mechs are broken, not mandatory in the clients and if they would be mandatory the OCSP servers would be target number 1 for DOS attacks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
In any case, this is drifting significantly off-topic. Anyone interested in continuing it further, please use other venues. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 00:40 schrieb Paul Wouters: On Tue, 30 Jun 2015, Michael Catanzaro wrote: What we basically do not want is to give the user an option for turning a security feature off. That's the same as saying remove the continue anyway frmo the browser. Only the human can determine if it is more important to be online insecurely or offline securely. At least we can hope when they click insecure that they won't go login to their banking site :P the more important question: who do gnome developers think they are to make such decisions? if someone wants the apple we know what you have to do way he can go out and by a apple machine - the reason for using a linux system is *exactly* the opposite signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 30 Jun 2015, Bastien Nocera wrote: Once DNSSEC is more widely deployed What is more widely deployed ? http://www.internetsociety.org/deploy360/wp-content/uploads/2013/04/2015-06-19-2015-06-19.png There are 991 zones in the root and 814 are signed and securely delegated. http://stats.labs.apnic.net/dnssec In North America and Europe, validation is about 20%. Overal in the world it is 12% It's really long overdue for us to make this the default and secure our users. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 2015-07-01 at 18:40 -0400, Paul Wouters wrote: That's the same as saying remove the continue anyway frmo the browser. Yeah, I want to do that too; actually I added it to Epiphany myself, not because it's a good idea, but because I know we'll be in for complaints otherwise, because Firefox and Chrome let you continue and we have to be just like them Basically all browser vendors agree that the Continue Anyway button was a huge mistake, but everyone is afraid to remove it for fear users will switch to a competing browser, so it's here to stay I'm afraid Anyway, if you think it's absolutely essential to have an opt-out, I guess we could have one buried in the network panel. But we don't want to advertise it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 30 Jun 2015, Michael Catanzaro wrote: I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). As a frequent traveler, I do have at times needed to go 'insecure' because VPN was blocked and DNS transparently redirected to a very broken server. In fact, right now this is happening to me, where all A records have no RRSIG and the entire root server list is stuffed in the additional section :P What we basically do not want is to give the user an option for turning a security feature off. That's the same as saying remove the continue anyway frmo the browser. Only the human can determine if it is more important to be online insecurely or offline securely. At least we can hope when they click insecure that they won't go login to their banking site :P Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays. Last time I found a broken site that I wanted to visit, I complained about it on my blog [1], and it got fixed. Actually, there was another time recently: I was planning to use the Bugzilla instance of a certain highly popular third-party distributor of software for Fedora, at the request of one of the developers, but it was broken (I think it used a worthless cacert), so I went on with my life instead. [1] https://blogs.gnome.org/mcatanzaro/2015/01/30/mozilla-is -responsible-for-the-redhat-corpmerchandise-com-fiasco/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 02:13 schrieb Michael Catanzaro: On Thu, 2015-07-02 at 00:44 +0200, Reindl Harald wrote: the more important question: who do gnome developers think they are to make such decisions? Hi Reindl, If you know enough about TLS to decide whether to click the Load Anyway button in your browser on a particular site, or enough about DNSSEC to know whether you want to disable validation, then congratulations: you are the 1%. That's great, but we are building an operating system that needs to be safe to use for the 99%. An operating system that requires users to make confusing security-related decisions is not safe to use. Constructing such an operating system is not ethical. oh and because i know enough you will make it impossible for me too instead describe the implications and in the best case lead users to a wiki page so that there will be more users knowing about in the future? If you know what a session cookie is, that clicking the Load Anyway button in your browser leaks it to attackers, and why that matters, then you are the privileged minority, and our software is not designed for you alone. Our free software will respect users -- the entire user population, not just the 1% -- or it will be bullshit [1]. I don't expect you to agree with me on this, but there you have it. :) i am the the privileged minority because i come before developers treated their users like idiots - if i would start these days working with computers i likely would not have the chance to become interested due the hide anything attitude signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 1 Jul 2015, Michael Catanzaro wrote: Date: Wed, 1 Jul 2015 19:26:55 From: Michael Catanzaro mcatanz...@gnome.org To: devel@lists.fedoraproject.org Subject: Re: dnssec-trigger + GNOME + NetworkManager integration On Wed, 2015-07-01 at 18:40 -0400, Paul Wouters wrote: That's the same as saying remove the continue anyway frmo the browser. Yeah, I want to do that too; actually I added it to Epiphany myself, not because it's a good idea, but because I know we'll be in for complaints otherwise, because Firefox and Chrome let you continue and we have to be just like them Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Anyway, if you think it's absolutely essential to have an opt-out, I guess we could have one buried in the network panel. But we don't want to advertise it. I guess I prefer a continue anyway with brief non-techniacl text, but beggars can't be choosers. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, 2015-07-02 at 00:44 +0200, Reindl Harald wrote: the more important question: who do gnome developers think they are to make such decisions? Hi Reindl, If you know enough about TLS to decide whether to click the Load Anyway button in your browser on a particular site, or enough about DNSSEC to know whether you want to disable validation, then congratulations: you are the 1%. That's great, but we are building an operating system that needs to be safe to use for the 99%. An operating system that requires users to make confusing security-related decisions is not safe to use. Constructing such an operating system is not ethical. If you know what a session cookie is, that clicking the Load Anyway button in your browser leaks it to attackers, and why that matters, then you are the privileged minority, and our software is not designed for you alone. Our free software will respect users -- the entire user population, not just the 1% -- or it will be bullshit [1]. I don't expect you to agree with me on this, but there you have it. :) Michael [1] http://mjg59.dreamwidth.org/32686.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - snip No, it is not. It is opt-in now, we want it by default. Please read the change. Thank you. I don't see any options about it in GNOME's Network panel. I'm not interested in integration as an after-thought. I think it best to stop this dead-end discussion until you've integrated DNSSEC support into NetworkManager. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 11:24, Tomas Hozza wrote: On 26.06.2015 17:13, Matthias Clasen wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. Yes, it should work. We didn't change anything related to that. We just had our own implementation. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. I was not able to determine if you rely on the system's stub resolver. If that is the case, NM should notify GNOME only after dnssec-trigger switches to hotspot signon mode. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.6.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. I'm afraid that this is the argument stopping DNSSEC from deployment, the usual chicken-egg problem. 'We cannot turn it on and be first because ... we do not know what will happen.' Does Fedora still hold to 'First'? Do we want to improve overall security? Where is the line? -- Petr^2 Spacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:46, Stef Walter wrote: On 30.06.2015 11:24, Tomas Hozza wrote: On 26.06.2015 17:13, Matthias Clasen wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. Yes, it should work. We didn't change anything related to that. We just had our own implementation. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. I was not able to determine if you rely on the system's stub resolver. If that is the case, NM should notify GNOME only after dnssec-trigger switches to hotspot signon mode. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Stef Right. I just tried to explain what insecure means in this context. I agree that insecure is so generic, that it is hard or even impossible to explain. Maybe something like use plain DNS vs. DNSSEC enabled is better. But even the existing hotspot signon mode is OK. It was just an idea, it is really the lowest priority issue, to rename the mode... Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - On 30.6.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. I'm afraid that this is the argument stopping DNSSEC from deployment, the usual chicken-egg problem. 'We cannot turn it on and be first because ... we do not know what will happen.' Does Fedora still hold to 'First'? Do we want to improve overall security? Where is the line? What you're asking users is to make a decision that they couldn't possibly understand, with security ramifications that you can't explain succinctly. Here's an analogy: we disable IPv4 by default, enable only IPv6, and when IPv6 fails on a particular network, you try to explain that they can't connect because IPv4 is insecure and toggle IPv4 on, and here be dragons. We're not going to enable DNSSEC by default if we can't figure out how to present the lack of it to users, and explain it. At least, a toggle in the Network configuration should help security conscious users enable it easily, and be the start of desktop integration. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:58, Stef Walter wrote: On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. No, it is not. It is opt-in now, we want it by default. Please read the change. Thank you. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Nobody ever said that we want to do that. This is exactly what we DON'T want to do. Stef Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. The good thing being that NetworkManager knows all that, and that the desktop doesn't need to track which network we connected to, and whether or not it used DNSSEC. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Exactly, cf. which firewall zone is this network in discussions of yesteryear. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. This argument is not valid. DNSSEC is usable even without being deployed everywhere. You are welcomed to turn the functionality off if you don't care about security, we would like to turn DNSSEC validation by default and are trying to find common ground to make it possible. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 14:11, Bastien Nocera wrote: - Original Message - On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. The good thing being that NetworkManager knows all that, and that the desktop doesn't need to track which network we connected to, and whether or not it used DNSSEC. I would not like GNOME to track anything network related. I think NM is good place for tracking network configuration. We don't want GNOME to track anything, but rather to provide UI for tools that are tracking the state. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Exactly, cf. which firewall zone is this network in discussions of yesteryear. I don't think we are interested in such discussion, since we don't think it is a good idea to expect regular users to do security related decisions. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 14:37, Bastien Nocera wrote: - Original Message - snip No, it is not. It is opt-in now, we want it by default. Please read the change. Thank you. I don't see any options about it in GNOME's Network panel. I'm not interested in integration as an after-thought. This is exactly what this email thread is all about... integration. I think it best to stop this dead-end discussion until you've integrated DNSSEC support into NetworkManager. I'm open to discussion. I don't have problem with you not continuing it. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 16:07, Michael Catanzaro wrote: On Tue, 2015-06-30 at 11:24 +0200, Tomas Hozza wrote: The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. I'm not sure I agree with that, from a desktop developer perspective. It's very convenient for GNOME (and probably also KDE) for NetworkManager to be the one-stop shop for network management. It already allows you to configure DNS anyway (in GNOME, under Network - hidden gear menu in the lower right - IPv4 or IPv6) so there has to be some level of integration to keep that working. This will still work. We are not going to interfere with the configuration that NM stores. If you configured explicit DNS servers, dnssec-trigger will still try to use those. However if they don't support DNSSEC, it will fallback to some other method. If by configuring DNS you mean writing content into resolv.conf, then NM will not do that any more. Instead we will use configuration from NM, including the user defined values. We will test the DNS servers and act upon the results of tests. There is a draft of the final configuration based on the network configuration [1]. Note that we don't care if the DNS servers came from DHCP or if user specified these manually. We act only on the final config provided by NM. [1] https://fedoraproject.org/w/index.php?title=Networking/NameResolution/DNSSEC/UnboundMixedMode#Usage Regards, Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-30 at 11:24 +0200, Tomas Hozza wrote: The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. I'm not sure I agree with that, from a desktop developer perspective. It's very convenient for GNOME (and probably also KDE) for NetworkManager to be the one-stop shop for network management. It already allows you to configure DNS anyway (in GNOME, under Network - hidden gear menu in the lower right - IPv4 or IPv6) so there has to be some level of integration to keep that working. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-30 at 14:23 +0200, Tomas Hozza wrote: Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). What we basically do not want is to give the user an option for turning a security feature off. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 16:07, Michael Catanzaro wrote: On Tue, 2015-06-30 at 14:23 +0200, Tomas Hozza wrote: Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). What we basically do not want is to give the user an option for turning a security feature off. Thank you for explanation. In that case we don't need any UI integration for this. Even though we use dnssec-trigger daily on our machines, we wanted to give the user a way to disable the feature if needed without the root access. This is more of a precaution in case something is broken and we didn't know about it. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 16:50, Tomas Hozza wrote: On 30.06.2015 16:07, Michael Catanzaro wrote: On Tue, 2015-06-30 at 14:23 +0200, Tomas Hozza wrote: Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). What we basically do not want is to give the user an option for turning a security feature off. Right. The UI is what people are balking against. Thank you for explanation. In that case we don't need any UI integration for this. Even though we use dnssec-trigger daily on our machines, we wanted to give the user a way to disable the feature if needed without the root access. This is more of a precaution in case something is broken and we didn't know about it. So this should then become a network setting and go into NetworkManager then, as one of its many options, and sit next to other DNS settings? Non-root users can perform limited network configuration (think wifi passwords and friends), so this isn't such a stretch. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 26.06.2015 17:13, Matthias Clasen wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. Yes, it should work. We didn't change anything related to that. We just had our own implementation. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. I was not able to determine if you rely on the system's stub resolver. If that is the case, NM should notify GNOME only after dnssec-trigger switches to hotspot signon mode. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. I could see adding information regarding the dnssec status of connections to the network panel. For that to happen, the information needs to be represented in the nm connection configuration, e.g. in NmSettingIP4Config, which already has settings like ignore-auto-dns. We can determine if the connection provided DNS resolvers are usable for DNSSEC validation, but that's it. There is no such thing as secure connection from DNS/DNSSEC point of view. The DNS resolvers for global name resolution are always taken from the default connection (if these are able to provide DNSSEC data) or full recursion is used or Fedora fallback infrastructure is used. Then for VPNs explicit forward zones are configured, with VPN provided DNS resolvers. So the bottom line is, that it does not make sense to distinguish security status of a connection from DNS/DNSSEC point of view, but rather the security status of the whole system and DNS resolution as a service provided by the system via stub resolver. 4. Additionally enable the user to trigger the reprobe of connection-provided DNS resolvers and display result of the probe (last one). - this should not be needed for regular use. It is more of a debugging tool I would encourage you to ship it separately as such, then. I don't even think it needs to be a graphical tool, a commandline utility would be just fine for this purpose. There is already a commandline tool that does all the things the GTK panel does. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - snip GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. Unfortunately on my system it doesn't launch browser, but I see captive portal icon on shell panel. Where to report bug, what info is needed? Against gnome-shell, upstream, and attach the section of journalctl around that event. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - Hello, On Tuesday, 23 June 2015 10:13 PM, Tomas Hozza wrote: Now we know that we have at least 3 components on the system, that are trying to do the same thing - Captive Portal detection: - dnssec-trigger - NetworkManager - GNOME Shell We don't have a problem with turning the detection off, however we need to agree on system-wide solution that works properly. True, couldn't agree more. +100 On Wednesday, 24 June 2015 12:47 AM, Michael Catanzaro wrote: Yes, that's correct. If NetworkManager's ConnectivityState is NetworkManager.ConnectivityState.PORTAL, then we launch a small (250 lines of code) GTK+ app with a WebKitWebView [1][2]. I expect that as long as NetworkManager's existing connectivity API is not broken, GNOME should be fine. If Gnome too depends on NetworkManager APIs, I wonder why is it separately conducting captive portal detection on its own? Michael just told you it's not doing captive portal detection on its own, it provides the login browser. IMHO NetworkManager is best placed and best suited to conduct network probes and notify other applications via its APIs. NM could be our one solid system wide solution for everything that is network. --- Regards -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. I could see adding information regarding the dnssec status of connections to the network panel. For that to happen, the information needs to be represented in the nm connection configuration, e.g. in NmSettingIP4Config, which already has settings like ignore-auto-dns. 4. Additionally enable the user to trigger the reprobe of connection-provided DNS resolvers and display result of the probe (last one). - this should not be needed for regular use. It is more of a debugging tool I would encourage you to ship it separately as such, then. I don't even think it needs to be a graphical tool, a commandline utility would be just fine for this purpose. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Jun 26, 2015 6:14 PM, Matthias Clasen mcla...@redhat.com wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. Unfortunately on my system it doesn't launch browser, but I see captive portal icon on shell panel. Where to report bug, what info is needed? 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. I could see adding information regarding the dnssec status of connections to the network panel. For that to happen, the information needs to be represented in the nm connection configuration, e.g. in NmSettingIP4Config, which already has settings like ignore-auto-dns. 4. Additionally enable the user to trigger the reprobe of connection-provided DNS resolvers and display result of the probe (last one). - this should not be needed for regular use. It is more of a debugging tool I would encourage you to ship it separately as such, then. I don't even think it needs to be a graphical tool, a commandline utility would be just fine for this purpose. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Hello, On Tuesday, 23 June 2015 10:13 PM, Tomas Hozza wrote: Now we know that we have at least 3 components on the system, that are trying to do the same thing - Captive Portal detection: - dnssec-trigger - NetworkManager - GNOME Shell We don't have a problem with turning the detection off, however we need to agree on system-wide solution that works properly. True, couldn't agree more. +100 On Wednesday, 24 June 2015 12:47 AM, Michael Catanzaro wrote: Yes, that's correct. If NetworkManager's ConnectivityState is NetworkManager.ConnectivityState.PORTAL, then we launch a small (250 lines of code) GTK+ app with a WebKitWebView [1][2]. I expect that as long as NetworkManager's existing connectivity API is not broken, GNOME should be fine. If Gnome too depends on NetworkManager APIs, I wonder why is it separately conducting captive portal detection on its own? IMHO NetworkManager is best placed and best suited to conduct network probes and notify other applications via its APIs. NM could be our one solid system wide solution for everything that is network. --- Regards -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnssec-trigger + GNOME + NetworkManager integration
Hi all. I would like to start a new fresh discussion where we can hopefully converge towards successful integration of default DNS resolver with NetworkManager on Fedora Workstation (GNOME). I think there are (at least) two major issues that need to be resolved: - system-wide Captive Portal detection - proper UI integration How is dnssec-trigger integrated with NM I'll start briefly with what dnssec-trigger does and how it is integrated with NM, so we are on the same boat. We use Unbound as local DNS resolver that does also DNSSEC validation. It needs to be configured with proper DNS forwarders in order to do the validation successfully. Dnssec-trigger is a daemon and script that reconfigures Unbound dynamically on every network change (using NetworkManager dispatcher). In our intended setup, dnssec-trigger handles the content of /etc/resolv.conf. It gathers all the current configuration from NM using libnm-glib. This means that we are able to handle any connection that NM is aware of, including VPNs and split DNS configuration. Our goal is to do DNSSEC validation whenever possible, therefore we have also public fallback Fedora infrastructure or DNS resolvers running on port 443. Since dnssec-trigger handles resolv.conf and reconfigures Unbound, NM's purpose is to do all the network configuration EXCEPT DNS related configuration. Captive Portal -- Dnssec-trigger also handles Captive Portal detection, since this situation is most of the times DNS spoofing attack and DNSSEC is exactly the mechanism that should protect users from such attack. Now we know that we have at least 3 components on the system, that are trying to do the same thing - Captive Portal detection: - dnssec-trigger - NetworkManager - GNOME Shell We don't have a problem with turning the detection off, however we need to agree on system-wide solution that works properly. We already know that the Captive Portal detection in NM relies on the system stub resolver, however after our previous discussion I was under the impression that there are some plans to rework it. Is this correct Dan? I hope that GNOME Shell somehow only displays the state provided by NM. Bastien, please correct me if I'm wrong and please elaborate on the details of what the functionality does (e.g. if you launch a new browser or so). In dnssec-trigger the detection is done by resolving a predefined hostname using DHCP-provided resolvers, downloading a remote file and then comparing the actual content with what was expected. This may not be perfect, but is mostly works. The important point is that DHCP provided resolvers are queried directly, not via system stub resolver. On the other hand, if NM dispatcher would be able to notify other services in case of detected Captive Portal, dnssec-trigger would be able to add the correct DHCP-provided resolver into the resolv.conf for the purpose of Logging into the Captive Portal. This is mainly due to the browser window using system's stub resolver. UI integration -- Now the dnssec-trigger comes with not really well integrated UI (dnssec-trigger panel) [2]. The panel is written in GTK2 and resides in the already deprecated status panel (on the bottom of the screen). It is used mainly for the following interaction with the user: - Inform the user about Captive Portal, in case there is one (to allow user to switch into so called hotspot signon mode) by pop-up window - enable user to switch to hotspot signon mode (basically insecure mode) manually - enable the user to reprobe DHCP-provided DNS servers if these are DNSSEC enabled - meaning to test if these are able to provide all the data needed for DNSSEC validation. - inform user in case the local network-provided DNS servers don't support DNSSEC and the local network blocks outgoing DNS communication on standard DNS ports and also when tunelled - in other words, user much choose between insecure mode or disconnecting from the network. This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually 4. Additionally enable the user to trigger the reprobe of connection-provided DNS resolvers and display result of the probe (last one). - this should not be needed for regular use. It is more of a debugging tool [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver [2]
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: I hope that GNOME Shell somehow only displays the state provided by NM. Bastien, please correct me if I'm wrong and please elaborate on the details of what the functionality does (e.g. if you launch a new browser or so). Yes, that's correct. If NetworkManager's ConnectivityState is NetworkManager.ConnectivityState.PORTAL, then we launch a small (250 lines of code) GTK+ app with a WebKitWebView [1][2]. I expect that as long as NetworkManager's existing connectivity API is not broken, GNOME should be fine. [1] https://git.gnome.org/browse/gnome -shell/tree/js/ui/status/network.js#n1964 [2] https://git.gnome.org/browse/gnome-shell/tree/js/portalHelper/main.js -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
