SSL Certificates for ripe anchors
Hi Has there been any dialog about moving the anchors away from using self signed certificates to Let's Encrypt? Regards Jóhann B.
On 2019-08-22 10:30, Jóhann B. Guðmundsson wrote:
Hi
Has there been any dialog about moving the anchors away from using self signed certificates to Let's Encrypt?
Regards
Jóhann B.
Hello, I believe there was no elaborate discussion about this so far. We do have TLSA records for all anchors which could be of help depending on what you want to achieve. Regards, Robert
On 8/30/19 10:07 AM, Robert Kisteleki wrote:
On 2019-08-22 10:30, Jóhann B. Guðmundsson wrote:
Hi
Has there been any dialog about moving the anchors away from using self signed certificates to Let's Encrypt?
Regards
Jóhann B. Hello,
I believe there was no elaborate discussion about this so far. We do have TLSA records for all anchors which could be of help depending on what you want to achieve.
What I'm trying to achieve is that ripe's anchors in data centers follow the latest security practices and standards, which require among other things a valid certificate issuer and associated CAA record for *.anchors.atlas.ripe.net anchors be it from Let's encrypt or Digicert, ripe's current certificate issuer Using a self signed certificate in today's age act's as an indicator that the security on the device or server in use might be in question ( if you cant even have an valid certificate issuer on the device or server when it's free, what other things are you skipping on, underlying OS and library updates, coding practices etc. ) and thus can negatively impact the anchor hosting provider security grade, which may lead to anchors having to be removed from data centers to prevent them from negatively affect corporation's security ratings. If money was the issue why the anchors got deployed with self signed certificates to begin with, that's not an issue anymore and probably the community can just get rid of Digicert and actually save money or use that money for lottery or beer on ripe event(s) . ;) Regards Jóhann B.
On 30. 08. 19 15:14, Jóhann B. Guðmundsson wrote:
On 8/30/19 10:07 AM, Robert Kisteleki wrote:
On 2019-08-22 10:30, Jóhann B. Guðmundsson wrote:
Hi
Has there been any dialog about moving the anchors away from using self signed certificates to Let's Encrypt?
Regards
Jóhann B. Hello,
I believe there was no elaborate discussion about this so far. We do have TLSA records for all anchors which could be of help depending on what you want to achieve.
What I'm trying to achieve is that ripe's anchors in data centers follow the latest security practices and standards, which require among other things a valid certificate issuer and associated CAA record for *.anchors.atlas.ripe.net anchors be it from Let's encrypt or Digicert, ripe's current certificate issuer
Using a self signed certificate in today's age act's as an indicator that the security on the device or server in use might be in question ( if you cant even have an valid certificate issuer on the device or server when it's free, what other things are you skipping on, underlying OS and library updates, coding practices etc. ) and thus can negatively impact the anchor hosting provider security grade, which may lead to anchors having to be removed from data centers to prevent them from negatively affect corporation's security ratings.
If money was the issue why the anchors got deployed with self signed certificates to begin with, that's not an issue anymore and probably the community can just get rid of Digicert and actually save money or use that money for lottery or beer on ripe event(s) . ;)
Hold your horses, self-signed cert with proper TLSA records in DNSSEC-signed domain is even better, see https://tools.ietf.org/html/rfc6698 . Besides other things correctly configured TLSA record + client side validation prevents rogue or compromised CAs from issuing "fake but accepted as valid" certs. So I would say RIPE NCC is attempting to do security it in the most modern way available. -- Petr Špaček @ CZ.NIC
Hi,
Hold your horses, self-signed cert with proper TLSA records in DNSSEC-signed domain is even better, see https://tools.ietf.org/html/rfc6698 .
Besides other things correctly configured TLSA record + client side validation prevents rogue or compromised CAs from issuing "fake but accepted as valid" certs.
So I would say RIPE NCC is attempting to do security it in the most modern way available.
Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who. Cheers, Sander
On 8/30/19 2:36 PM, Sander Steffann wrote:
Hi,
Hold your horses, self-signed cert with proper TLSA records in DNSSEC-signed domain is even better, see https://tools.ietf.org/html/rfc6698 .
Besides other things correctly configured TLSA record + client side validation prevents rogue or compromised CAs from issuing "fake but accepted as valid" certs.
So I would say RIPE NCC is attempting to do security it in the most modern way available. Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who.
The third parties that "certify" are for others to establish trust in that you are who you claim to be not because its "required" and the security industry has deemed those who do not atleast get some other entity to validate, not to be worthy of trust. Just because Trump says he's a genius and the "chosen one" does not make him one now does it... JBG
Hi, On Fri, Aug 30, 2019 at 03:08:06PM +0000, Jóhann B. Guðmundsson wrote:
Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who.
The third parties that "certify" are for others to establish trust in that you are who you claim to be not because its "required" and the security industry has deemed those who do not atleast get some other entity to validate, not to be worthy of trust.
TLSA does all this, without requiring some other entity that follows their own agenda to "certify" anything. You need to trust the DNS root KSK, of course, but everything else follows the normal DNSSEC chain.
Just because Trump says he's a genius and the "chosen one" does not make him one now does it...
No, but that is slighly missing the point. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Le 30/08/2019 à 20:32, Gert Doering a écrit :
Hi,
On Fri, Aug 30, 2019 at 03:08:06PM +0000, Jóhann B. Guðmundsson wrote:
Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who. The third parties that "certify" are for others to establish trust in that you are who you claim to be not because its "required" and the security industry has deemed those who do not atleast get some other entity to validate, not to be worthy of trust. TLSA does all this, without requiring some other entity that follows their own agenda to "certify" anything. You need to trust the DNS root KSK, of course, but everything else follows the normal DNSSEC chain.
Not quite true, you also need to trust your registrar, as they could change the enrolled DNSSEC key and glue records. Though this is way more visible than a rogue certificate used ponctually for some targets. ;)
Sander Steffann <sander@steffann.nl> writes:
Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who.
+1 There is still too much money in the CA business. Which is the reason why no major browser does TLSA validation. And why "best practices" allow, or even recommend, inferior solutions like CAA, HPKP and other bad ideas instead of DANE. You gotta look at the source of those recommendations. They are most likely "best" for someones wallet. Not necessarily for security. It's amazing that they still try to make those pigs fly. Bjørn
On Fri, Aug 30, 2019, 18:34 Bjørn Mork <bjorn@mork.no> wrote:
Sander Steffann <sander@steffann.nl> writes:
Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who.
+1
There is still too much money in the CA business.
I would argue not but given that ripe itself is still paying digicert that arguement would be muted Which is the reason
why no major browser does TLSA validation.
*<Citation needed>* And why "best practices"
allow, or even recommend, inferior solutions like CAA, HPKP and other bad ideas instead of DANE.
How on earth is having a CAA record which pin points who is allowed to issue certificates on your behalf an inferiour solution. A RR that you use with DANE btw o_O You gotta look at the source of those
recommendations. They are most likely "best" for someones wallet. Not necessarily for security.
Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free... It's amazing that they still try to make those pigs fly.
Who are they? The evil certificate cabal that is out to destroy the world? Do I need to start wearing my tin foil hat when I go out riding and storm area 51 while i'm at it ;) In anycase to stay on topic. If the person or team that is responsible for the certificates on anchors can answer why they choose to use self signed certs, and why the ripe community is still paying for digicert when there is equally good, free signed alternative in an open community available,that would be good. If the answer is "we have not gotten around to it yet, but are planning to switch to let's encrypt for our self signed and paid certificates" *wink*wink**nudge*nudge* that would be even better. Thanks JBG
Jóhann B. Guðmundsson <johannbg@gmail.com> writes:
How on earth is having a CAA record which pin points who is allowed to issue certificates
No, it doesn't. It's merely a hint to CAs. It cannot prevent spoofed certificates if any CA is compromised, or fails to validate the CAA record for other reasons. TLS clients are unable to detect spoofed certificates using CAA, since there is no sane way to map between CA certificate and the CAA record. It depends on ultimate trust in every browser root CA. CAA is mostly smoke and mirrors. TLSA allows you to pin CA certificates or server certificates so that it can be validated by everyone. It will protect against rogue or compromised CAs. And you don't need to trust any of them. You can pin your own certificate instead. Yes, CAA is inferior. It would have been funny if it wasn't for the fact that people actually believe in this stuff. Bjørn
Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free...
TL;DR if the community prefers it we use LE (+TLSA). This comes with the expense of some one-time and ongoing operational work. Considering that anchors don't host any sensitive information, using self-signed certs (+TLSA) was so far considered good enough. Regards, Robert
Hi Robert, all: As a disclaimer, I'm not an engineer/programmer, so I don't know all the technical specifications. However, I am a big advocate for Let's Encrypt, and think it sends a strong message about the service they offer if the RIPE community and NCC endorses them for our networks and infrastructure. So, take my vote with a grain of salt, but I say let's do it (barring any kind of technical issue that I'm simply not aware of). Best, -Michael On Tue, Sep 3, 2019 at 9:58 AM Robert Kisteleki <robert@ripe.net> wrote:
Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free...
TL;DR if the community prefers it we use LE (+TLSA).
This comes with the expense of some one-time and ongoing operational work. Considering that anchors don't host any sensitive information, using self-signed certs (+TLSA) was so far considered good enough.
Regards, Robert
Hi all, Le 9/3/2019 à 10:00 AM, Michael J. Oghia a écrit :
Hi Robert, all:
As a disclaimer, I'm not an engineer/programmer, so I don't know all the technical specifications. However, I am a big advocate for Let's Encrypt, and think it sends a strong message about the service they offer if the RIPE community and NCC endorses them for our networks and infrastructure. So, take my vote
I second this, and i also support the main *alert* raised by Jóhann. ...i can add this : if there is a technical issue (not impossible) in using LE certs the same way the actual solution is used on RIPE Anchors, then perhaps, preferably, RIPE *should* contribute to fund whatever necessary to solve the problem on LE side or internally. ...so : where to take the money ? simply reorientate a part of the money used for the actual solution :-/ Thanks. Shalom, --sb.
with a grain of salt, but I say let's do it (barring any kind of technical issue that I'm simply not aware of).
Best, -Michael
On Tue, Sep 3, 2019 at 9:58 AM Robert Kisteleki <robert@ripe.net <mailto:robert@ripe.net>> wrote:
[...]
-- Regards, Sylvain B. <http://www.chretiennement.org> __ Website : <https://www.cmnog.cm> Wiki : <https://www.cmnog.cm/dokuwiki> Surveys : <https://survey.cmnog.cm> Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/> Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>
Sylvain, all - On 03.09.2019 13:12, Sylvain BAYA wrote:
[...]
...i can add this : if there is a technical issue (not impossible) in using LE certs the same way the actual solution is used on RIPE Anchors, then perhaps, preferably, RIPE *should* contribute to fund whatever necessary to solve the problem on LE side or internally.
indeed there is: one way to use Letsencrypt certificates is to have them automagically renewd every 90 days or so. This works like a charm on my host. The tricky bit, however, comes if you want to use this very certificate in a TLSA RR as well: all of a sudden the RR points to a non-existing certificate when Letsencrypt's cron job has flipped the certificate. I haven't yet really gotten my head around it - but maybe the NCC could and would?! 8-) Chers, -C.
Carsten Schiefner <carsten@schiefner.de> writes:
The tricky bit, however, comes if you want to use this very certificate in a TLSA RR as well: all of a sudden the RR points to a non-existing certificate when Letsencrypt's cron job has flipped the certificate.
I haven't yet really gotten my head around it - but maybe the NCC could and would?! 8-)
You can renew Let's Encrypt certificates without changing the key. And if you use the recommended 3 1 1 TLSA records, then you don't have to change it unless the key is changed. Bjørn
Hi Bjørn,
Am 03.09.2019 um 13:35 schrieb Bjørn Mork <bjorn@mork.no>:
The tricky bit, however, comes if you want to use this very certificate in a TLSA RR as well: all of a sudden the RR points to a non-existing certificate when Letsencrypt's cron job has flipped the certificate.
[...]
You can renew Let's Encrypt certificates without changing the key. And if you use the recommended 3 1 1 TLSA records, then you don't have to change it unless the key is changed.
ah! :-) Would you have a specific pointer in mind you’d recommend and so like to share? Thanks & best, -C.
Hi all, Le 9/3/2019 à 1:34 PM, Carsten Schiefner a écrit :
[...] You can renew Let's Encrypt certificates without changing the key. And if you use the recommended 3 1 1 TLSA records, then you don't have to change it unless the key is changed. ah! :-)
Would you have a specific pointer in mind you’d recommend and so like to share?
Dear Carsten, ...i've started to read this <https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022> one. Hope you will find it relevant. Thanks. Shalom, --sb.
Thanks & best,
-C.
-- Regards, Sylvain B. <http://www.chretiennement.org> __ Website : <https://www.cmnog.cm> Wiki : <https://www.cmnog.cm/dokuwiki> Surveys : <https://survey.cmnog.cm> Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/> Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>
Carsten Schiefner <carsten@schiefner.de> writes:
Am 03.09.2019 um 13:35 schrieb Bjørn Mork <bjorn@mork.no>:
The tricky bit, however, comes if you want to use this very certificate in a TLSA RR as well: all of a sudden the RR points to a non-existing certificate when Letsencrypt's cron job has flipped the certificate.
[...]
You can renew Let's Encrypt certificates without changing the key. And if you use the recommended 3 1 1 TLSA records, then you don't have to change it unless the key is changed.
ah! :-)
Would you have a specific pointer in mind you’d recommend and so like to share?
I believe this covers it: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-r... And RFC 7671 is also a nice reference, especially if you want to roll keys. Bjørn
[https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-r...] Thanks, Sylvain and Bjørn! -- Von meinem Android-Gerät gesendet. -----Original Message----- From: Carsten Schiefner <carsten@schiefner.de> To: "Bjørn Mork" <bjorn@mork.no> Cc: ripe-atlas@ripe.net Sent: Di., 03 Sep. 2019 14:34 Subject: Re: [atlas] SSL Certificates for ripe anchors Hi Bjørn,
Am 03.09.2019 um 13:35 schrieb Bjørn Mork <bjorn@mork.no>:
The tricky bit, however, comes if you want to use this very certificate in a TLSA RR as well: all of a sudden the RR points to a non-existing certificate when Letsencrypt's cron job has flipped the certificate.
[...]
You can renew Let's Encrypt certificates without changing the key. And if you use the recommended 3 1 1 TLSA records, then you don't have to change it unless the key is changed.
ah! :-) Would you have a specific pointer in mind you’d recommend and so like to share? Thanks & best, -C.
On 3 Sep 2019, at 15:10, Carsten Schiefner wrote:
[https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-r...]
Thanks, Sylvain and Bjørn!
And of course ‘our own’ Jan Žorž explains this quite well too: https://www.internetsociety.org/blog/2016/01/lets-encrypt-certificates-for-m...
Hi all, Le 9/3/2019 à 12:24 PM, Carsten Schiefner a écrit :
Sylvain, all -
On 03.09.2019 13:12, Sylvain BAYA wrote:
[...] indeed there is: one way to use Letsencrypt certificates is to have them automagically renewd every 90 days or so.
This works like a charm on my host.
The tricky bit, however, comes if you want to use this very certificate in a TLSA RR as well: all of a sudden the RR points to a non-existing certificate when Letsencrypt's cron job has flipped the certificate.
Dear Carsten, Thanks for pointing this clear issue here :-) ...do you think it is a configuration issue or a technical (conceptual) one ? I suppose that you have already pointed it to the LE team :-/
I haven't yet really gotten my head around it - but maybe the NCC could and would?! 8-)
...you might have a great support now, if RIPE NCC accepts (if need be) to jump in ;-) Shalom, --sb.
Chers,
-C.
-- Regards, Sylvain B. <http://www.chretiennement.org> __ Website : <https://www.cmnog.cm> Wiki : <https://www.cmnog.cm/dokuwiki> Surveys : <https://survey.cmnog.cm> Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/> Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>
Robert, On 03/09/2019 09.57, Robert Kisteleki wrote:
Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free...
TL;DR if the community prefers it we use LE (+TLSA).
This comes with the expense of some one-time and ongoing operational work. Considering that anchors don't host any sensitive information, using self-signed certs (+TLSA) was so far considered good enough.
Sorry for asking this question so late in this thread, but what exactly are the certificates used for? The value of a certificate from a certificate authority is that you outsource the work of establishing a trust relationship. If you're connecting bits of networking infrastructure together, presumably one's provisioning tools can configure each component with exactly the secrets and trust needed, so self-signed certificates should be fine (or better, since the system is simpler and there is no dependency on external infrastructure). If the use case under discussion is to help RIPE anchor operators (or others) to see some status page on the anchor itself via a browser, then using a "real" certificate might make sense. Otherwise, I don't see the point. Cheers, -- Shane
On 2019-09-03 11:17, Shane Kerr wrote:
Robert,
On 03/09/2019 09.57, Robert Kisteleki wrote:
Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free...
TL;DR if the community prefers it we use LE (+TLSA).
This comes with the expense of some one-time and ongoing operational work. Considering that anchors don't host any sensitive information, using self-signed certs (+TLSA) was so far considered good enough.
Sorry for asking this question so late in this thread, but what exactly are the certificates used for?
The anchors provide very basic services intended to help users who want to use the anchors as measurement targets. They answer incoming ping, DNS and HTTP(S) queries (see https://atlas.ripe.net/docs/anchors/). The HTTP(S) service can respond with pages of various sizes which is intended to help PMTUD tests for example. It's possible that someone would want to check the TLS certificate of the measured anchor, in which case a "proper" certificate may come handy. Regards, Robert
On 3 Sep 2019, at 11:38, Robert Kisteleki wrote:
On 2019-09-03 11:17, Shane Kerr wrote:
… Sorry for asking this question so late in this thread, but what exactly are the certificates used for?
The anchors provide very basic services intended to help users who want to use the anchors as measurement targets. They answer incoming ping, DNS and HTTP(S) queries (see https://atlas.ripe.net/docs/anchors/). The HTTP(S) service can respond with pages of various sizes which is intended to help PMTUD tests for example.
It's possible that someone would want to check the TLS certificate of the measured anchor, in which case a "proper" certificate may come handy.
Regards, Robert
Going back to Jóhann, who brought this up: “Using a self signed certificate in today's age act's as an indicator that the security on the device or server in use might be in question … and thus can negatively impact the anchor hosting provider security grade, which may lead to anchors having to be removed from data centers to prevent them from negatively affect corporation's security ratings.” So we have devices that expose the https port and respond with a self signed cert. Any security audit will flag that. Rather than explain to the auditors that there is no ‘real’ http service here, it is a measurement device, … Jóhann suggests to put an acceptably signed cert there. To me this sounds like a no-brainer to make life easier for anchor hosts and not an ideological issue about which CA to use or about other methods of securing https. So can we deploy certs that will satisfy the security audit and get on with life? Daniel
been using LE+TLSA for a loooong time. like 94 of us, i have recipies (for LE for sites w/o web services) if you need them. please do it. it's prudent. randy
On 2019-09-03 17:03, Randy Bush wrote:
been using LE+TLSA for a loooong time. like 94 of us, i have recipies (for LE for sites w/o web services) if you need them. please do it. it's prudent.
randy
Thank you Randy for the offer! We'll check what it takes to add this to the anchors, and report back soon. Regards, Robert
Just to weigh in as both an Anchor host and a heavy Atlas user: we've found the self-signed certificates to be a non-issue. While I will not deny that they do show up in many internal security scans, self-signed certs fall well below other "issues" such as open ports, non-standard responses to version.bind queries, and strange traffic patterns. Such concerns are, however, mitigated by the understanding that the anchors are measurement points, and therefore may generate, and be subject to, non-standard (or perceived as traditionally insecure) behaviors. I can appreciate that there may be measurements (*i.e. *using the platform) that would be made easier with non-self-signed certificates, but I'm not sure I've seen that discussed here. -m On Wed, Sep 4, 2019 at 3:00 AM Robert Kisteleki <robert@ripe.net> wrote:
On 2019-09-03 17:03, Randy Bush wrote:
been using LE+TLSA for a loooong time. like 94 of us, i have recipies (for LE for sites w/o web services) if you need them. please do it. it's prudent.
randy
Thank you Randy for the offer!
We'll check what it takes to add this to the anchors, and report back soon.
Regards, Robert
-- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 <https://www.peeringdb.com/asn/15133> e: marcel.flores@verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094
There is still too much money in the CA business.
well, though on the surface i agree, i do not take it as a motivation to add one more chunk of sysadmin.
Which is the reason why no major browser does TLSA validation.
well. there is the extra protocol turn. agl tried and backed off, seemingly because of that. but, if we want to encourage tlsa, recommended values for the three lovely but obscure (after all, it is the dns) parameters. victor whacked me into using 211 with let's encrypt certs. randy
Randy Bush <randy@psg.com> writes:
Which is the reason why no major browser does TLSA validation.
well. there is the extra protocol turn. agl tried and backed off, seemingly because of that.
I hear that. And I see them pushing DNS over HTTPS at the same time. Doesn't really compute... They are so good at making up excuses. A couple of yours ago they didn't need TLSA validation beacuse HPKP was so much better: https://www.imperialviolet.org/2015/01/17/notdane.html Where did that go? Oh, yes, turns out it wasn't such a good idea anyway: https://ordina-jworks.github.io/security/2018/02/12/HPKP-deprecated-what-now... So now we're back to ultimate trust in the CAs again, using CT and CAA. Nice move.
but, if we want to encourage tlsa, recommended values for the three lovely but obscure (after all, it is the dns) parameters. victor whacked me into using 211 with let's encrypt certs.
I prefer 3 1 1 for my certs, pinning my own key regardless of who else signed it. Bjørn
On Fri, Aug 30, 2019, 20:30 Randy Bush <randy@psg.com> wrote:
There is still too much money in the CA business.
well, though on the surface i agree, i do not take it as a motivation to add one more chunk of sysadmin.
Which is the reason why no major browser does TLSA validation.
well. there is the extra protocol turn. agl tried and backed off, seemingly because of that.
The problem with the added extra lookup which added more latency, which increased the chances for packet loss, causing expensive timeouts and retransmitions had been somewhat worked on but abandoned [1] and wont be revisited due to [2] being the browser community take on this afaik. Given that Let's encrypt own root which was supposed to be pushed out this July but got delayed til 2020 is widely trusted by browser, one can hardly claim that the browser community is run by some "cert cabal" If the "cert cabal" will try anything it will be to block acceptance and or usage of self and Let's encrypt signed certs with high profile cloud providers because that's where the money is and corporates are somewhat vendor locked in there, which makes them an easy pray for additional fees.. JBG 1. https://www.imperialviolet.org/2011/06/16/dnssecchrome.html 2. http://www.certificate-transparency.org
Hi, On Fri, Aug 30, 2019 at 09:59:02PM +0000, Jóhann B. Guðmundsson wrote:
Given that Let's encrypt own root which was supposed to be pushed out this July but got delayed til 2020 is widely trusted by browser, one can hardly claim that the browser community is run by some "cert cabal"
Well, the pieces sort of nicely fit. Push everybody to do "https everywhere!" (why not? LE is free!), and of course for *real* security companies must have EV certs from "real" CAs... for heaps of money. Money flows. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Push everybody to do "https everywhere!" (why not? LE is free!), and of course for *real* security companies must have EV certs from "real" CAs... for heaps of money.
upcoming chrome and ffox will not green light ev randy
participants (14)
-
Bjørn Mork -
Bruno Pagani -
Carsten Schiefner -
Daniel Karrenberg -
Gert Doering -
Jóhann B. Guðmundsson -
Marcel Flores -
Michael J. Oghia -
Petr Špaček -
Randy Bush -
Robert Kisteleki -
Sander Steffann -
Shane Kerr -
Sylvain BAYA