Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Randy Bush
been using LE+TLSA for a lng 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



Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Daniel Karrenberg




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-records-with-le-certificates/7022]

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-mail-servers-and-dane-part-1-of-2/



Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Carsten Schiefner
[https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022]

Thanks, Sylvain and Bjørn!

-- 
Von meinem Android-Gerät gesendet.

-Original Message-
From: Carsten Schiefner 
To: "Bjørn Mork" 
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 :
>> 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.




Re: [atlas] User Tags missing [ProbeTag object]

2019-09-03 Thread Johan ter Beest
Hi Alexey,

> On 1 Sep 2019, at 11:41, Alexey Troshchanovich  wrote:
> 
> Hello team,
> 
> Unfortunately, in "Messages" (https://atlas.ripe.net/messages/ 
> ) system tags are still displayed as 
> "ProbeTag object".
> 
> Your probe #x was automatically tagged (or untagged) as "ProbeTag object"
> 
> Could you also have a look at "Sponsored by: Sponsor object" in the list of 
> anchors?

These issues have now also been fixed, thank you for reporting :)

Please note that in the case of the messages, you will still see ProbeTag 
object for the older entries, but newer entries should show the actual tag name 
again.

The root cause of these issues was upgrading our code base from Python 2.7 to 
Python 3.6. They were only display issues as Python 3 handles unicode strings 
differently than Python 2

Kind regards,
Johan ter Beest
RIPE NCC

> 
> Thank you.
> 
> Alexey
> 
> On Tue, Aug 27, 2019 at 6:09 PM yves croison  > wrote:
> at home it's good I found my tags.
> thank you
> Le 27/08/2019 à 15:48, Chris Amin a écrit :
>> Dear Jiri,
>> 
>> Thanks for reporting this. It has now been fixed, so tags should display
>> as normal!
>> 
>> Regards,
>> Chris Amin
>> RIPE NCC
>> 
>> On 27/08/2019 13:16, r...@brite.cz  wrote:
>>> Hi team,
>>> all User Tags on all probes I checked are showing string "ProbeTag object" 
>>> only.
>>> Please have a look.
>>> 
>>> Thank you
>>> Jiri
>>> 
>>> 



smime.p7s
Description: S/MIME cryptographic signature


Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Bjørn Mork
Carsten Schiefner  writes:
>> Am 03.09.2019 um 13:35 schrieb Bjørn Mork :
>>> 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-records-with-le-certificates/7022

And  RFC 7671 is also a nice reference, especially if you want to roll
keys.



Bjørn



[atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Sylvain BAYA
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

one.
Hope you will find it relevant.

Thanks.
Shalom,
--sb.

>
> Thanks & best,
>
> -C.
>
-- 

Regards,
Sylvain B.
 
__
Website : 
Wiki : 
Surveys : 
Subscribe to Mailing List : 
Mailing List's Archives : 



0x0387408365AC8594.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Carsten Schiefner
Hi Bjørn,

> Am 03.09.2019 um 13:35 schrieb Bjørn Mork :
>> 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.



[atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Sylvain BAYA
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.
 
__
Website : 
Wiki : 
Surveys : 
Subscribe to Mailing List : 
Mailing List's Archives : 



0x0387408365AC8594.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Bjørn Mork
Carsten Schiefner  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



Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Carsten Schiefner
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.



[atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Sylvain BAYA
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  > wrote:
>
>
> [...]
>
-- 

Regards,
Sylvain B.
 
__
Website : 
Wiki : 
Surveys : 
Subscribe to Mailing List : 
Mailing List's Archives : 



0x0387408365AC8594.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Daniel Karrenberg





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



Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Robert Kisteleki



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



Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Shane Kerr

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



Re: [atlas] SSL Certificates for ripe anchors

2019-09-03 Thread Robert Kisteleki


> 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