Re: Securely managing TLS certificates on growing server (website, XMPP, soon email)?
Thank you, this resolves that concern of mine (and in fact, it was an elegant
enough solution that I felt silly for not doing it that way before). :) It makes
a lot more sense to have acme-client(1) place the exceptional certificates in a
different spot, rather than modify `/etc/ssl/private` to make everything work in
one location.
On 22/12/16 11:16, Omar Polo wrote:
> Can only speak for prosody as it's the only non-base daemon I'm
> getting TLS certificates for; my strategy with it has been to generate
> a different certificate and to deliver it in a place where only
> prosody can read it. Luckily, the prosody package installs
> /etc/prosody/certs owned by _prosody alone.
>
> # /etc/acme-client.conf
> domain xmpp {
> domain name example.com
> alternative names { room.example.com upload.example.com }
> domain key "/etc/prosody/certs/example.com.key"
> domain full chain certificate
> "/etc/prosody/certs/example.net.crt"
> sign with letsencrypt
> }
>
> note the `domain' name is "xmpp" because I have another `domain' block
> for the same domain (but different alt names) for httpd:
>
> # only for httpd
> domain example.com {
> alternative names { www.example.com }
> ...
> }
>
> all handled by cron as usual:
>
> ~ * * * * acme-client example.com && rcctl reload httpd
> ~ * * * * acme-client xmpp && rcctl restart prosody
>
> in prosody.conf.lua i have
>
> certificates = "certs"
>
> I also have some symlinks in /etc/prosody/certs in the form:
>
> {room,upload}.example.com.crt -> example.com.crt
> {room,upload}.example.com.key -> example.com.key
>
> so that prosody can look up the certs by itself without extra
> configuration. Can probably do it without the symlinks, but I was
> lazy and this worked for me.
>
> HTH
Re: Stretch/L2VPN between two datacenters
I've run L2 over an IPsec tunnel using egre (gre(4)) and bridge (bridge (4)) to connect systems in different locations together. This was done before David Gwynne created tpmr(4). I've been to lazy to reimplement my current configuration. 73 diana
Re: Stretch/L2VPN between two datacenters
On Fri, Dec 16, 2022 at 11:39:02AM +0100, Hrvoje Popovski wrote: > On 16.12.2022. 11:33, Lars Bonnesen wrote: > > We are about to migrate VM's from one datacenter to another and the VMware > > L2VPN we are using for this is simply not stable for some reason that we > > cannot figure out why. > > > > I have used GRE-tunneling before on a software router that I actually > > cannot remember the name of now, but if OpenBSD can do the same, I would > > rather deploy one OpenBSD on each site and have that task handled by > > OpenBSD. > > > > Each site should be able to use the other site gateway over a > > L2-network.and VMs on each site should be able to see each other as they > > are on the same LAN > > > > Where to start reading? > > > man tpmr yes. i wrote tpmr for this exact situation. i wanted to connect switches in different datacentres together over tunnels (etherip in my case) while i was migrating from one site to the other. i was considering calling the driver xconnect or xcon, but went with tpmr because i was reading the ethernet bridge specification at the time and it talks about a special type of bridge called a two port mac relay.
Re: Stretch/L2VPN between two datacenters
Dnia 16 grudnia 2022 11:33:55 CET, Lars Bonnesen napisał/a: >We are about to migrate VM's from one datacenter to another and the VMware >L2VPN we are using for this is simply not stable for some reason that we >cannot figure out why. > >I have used GRE-tunneling before on a software router that I actually >cannot remember the name of now, but if OpenBSD can do the same, I would >rather deploy one OpenBSD on each site and have that task handled by >OpenBSD. > >Each site should be able to use the other site gateway over a >L2-network.and VMs on each site should be able to see each other as they >are on the same LAN > >Where to start reading? > >Regards, Lars. You could use vxlan and bridge it to physical interface. If you need to also encrypt that traffic, then vxlan over ipsec Or openvpn in layer 2 (tap mode), then bridge tap0 on both ends to physical interface Regards -- Łukasz Moskała
Re: Securely managing TLS certificates on growing server (website, XMPP, soon email)?
Hi Ashlen, The best way to handle your concerns is to review httpd, OpenSMTPd, and other projects code and send a patch to these project to handle Certificates in a more secure way. This way you can help yourself and the others. Bests, Ali Farzanrad Ashlen wrote: > Hi all, so I'm wondering how to securely deal with TLS certificates on a > server > that's grown to host multiple services (website, XMPP, soon email as well). > Specifically how to handle permissions and to what degree certificates should > be > separated. > > (I recognize this is a long email. I'm unsure how to break down my thoughts > further) > > I know that I could add a load of Subject Alternative Names to one big > certificate, but I have a couple of concerns with this. > > 1) If I understand it right, if there's a security issue with one program and > an > attacker gains arbitrary read, and the effective user id can read the private > key, the exposure is greater than it has to be (that is to say, domains that > are > completely unrelated to the insecure program are exposed). Daemons outside of > base unfortunately often lack privilege separation to the extent that it > exists > in base, so there may not be a separate user to handle private keys, and then > the whole thing has the potential to blow up later. > > 2) A long list of Subject Alternative Names means that anyone connecting to > the > web server can see all of the additional subdomains that are unrelated to the > web server being hosted. This is really a nitpick compared to the first point, > as even without this being the case there are other methods of enumeration and > discovery (nmap and friends), and relying on DNS entries being hidden seems > like > a bad idea. > > The best way I can think of how to handle this so far, and "best" is used very > loosely since I don't think it's a perfect solution, is to split the keys up, > add a separate group, and modify `/etc/ssl/private`. > > ``` > # groupadd tls > # usermod -G tls _prosody > # chown root:tls /etc/ssl/private > # chmod 750 /etc/ssl/private > ``` > > Then the private keys within would all have 0400 permissions, user and group > being the same (so _prosody:_prosody for XMPP-related TLS). I noted that the > default is 700 permissions on `/etc/ssl/private` with root:wheel ownership. Is > the approach I've just outlined with adding a group and modifying permissions > a > bad idea? > > Even if it makes sense to do it this way, I still have a separate issue in > that > when two or more services need the certificate for the root domain, they'll > end > up sharing it, and I'm unclear what the right way to fix that problem is. If > it's only services in the base system, that's one thing. But Prosody also has > this issue with the way I set it up. Currently it's configured so that > usernames > can be in the form "u...@example.com" rather than "u...@xmpp.example.com" > (similar to how email usernames use the root domain). This means it needs the > certificate for the root domain so that authentication can take place over > TLS, > and that breaks the separation. > > For some services, it can make sense to use relayd(8) and let that handle TLS > instead, which simplifies things since relayd has proper privilege separation > and can even use SNI. But I'm unsure how this could be done with something > like > Prosody since XMPP uses STARTTLS (outside of exceptions to that rule like > XEP-0368). > > What can I do to manage this better? Any ideas/suggestions are very welcome. > Thank you for reading all of this if you made it here. > >
Re: Stretch/L2VPN between two datacenters
On 16.12.2022. 11:33, Lars Bonnesen wrote: > We are about to migrate VM's from one datacenter to another and the VMware > L2VPN we are using for this is simply not stable for some reason that we > cannot figure out why. > > I have used GRE-tunneling before on a software router that I actually > cannot remember the name of now, but if OpenBSD can do the same, I would > rather deploy one OpenBSD on each site and have that task handled by > OpenBSD. > > Each site should be able to use the other site gateway over a > L2-network.and VMs on each site should be able to see each other as they > are on the same LAN > > Where to start reading? man tpmr
Stretch/L2VPN between two datacenters
We are about to migrate VM's from one datacenter to another and the VMware L2VPN we are using for this is simply not stable for some reason that we cannot figure out why. I have used GRE-tunneling before on a software router that I actually cannot remember the name of now, but if OpenBSD can do the same, I would rather deploy one OpenBSD on each site and have that task handled by OpenBSD. Each site should be able to use the other site gateway over a L2-network.and VMs on each site should be able to see each other as they are on the same LAN Where to start reading? Regards, Lars.
Re: Securely managing TLS certificates on growing server (website, XMPP, soon email)?
On 2022/12/15 13:56:00 -0700, Ashlen wrote:
> Hi all, so I'm wondering how to securely deal with TLS certificates on a
> server
> that's grown to host multiple services (website, XMPP, soon email as well).
> Specifically how to handle permissions and to what degree certificates should
> be
> separated.
>
> (I recognize this is a long email. I'm unsure how to break down my thoughts
> further)
>
> I know that I could add a load of Subject Alternative Names to one big
> certificate, but I have a couple of concerns with this.
>
> 1) If I understand it right, if there's a security issue with one program and
> an
> attacker gains arbitrary read, and the effective user id can read the private
> key, the exposure is greater than it has to be (that is to say, domains that
> are
> completely unrelated to the insecure program are exposed). Daemons outside of
> base unfortunately often lack privilege separation to the extent that it
> exists
> in base, so there may not be a separate user to handle private keys, and then
> the whole thing has the potential to blow up later.
>
> 2) A long list of Subject Alternative Names means that anyone connecting to
> the
> web server can see all of the additional subdomains that are unrelated to the
> web server being hosted. This is really a nitpick compared to the first point,
> as even without this being the case there are other methods of enumeration and
> discovery (nmap and friends), and relying on DNS entries being hidden seems
> like
> a bad idea.
>
> The best way I can think of how to handle this so far, and "best" is used very
> loosely since I don't think it's a perfect solution, is to split the keys up,
> add a separate group, and modify `/etc/ssl/private`.
>
> ```
> # groupadd tls
> # usermod -G tls _prosody
> # chown root:tls /etc/ssl/private
> # chmod 750 /etc/ssl/private
> ```
>
> Then the private keys within would all have 0400 permissions, user and group
> being the same (so _prosody:_prosody for XMPP-related TLS). I noted that the
> default is 700 permissions on `/etc/ssl/private` with root:wheel ownership. Is
> the approach I've just outlined with adding a group and modifying permissions
> a
> bad idea?
Personally, I wouldn't deviate from the os defaults by changing the
permission on /etc/ssl/private.
it seems fragile, and you'd also need to make sure permissions are
kept when updating the certificates.
> Even if it makes sense to do it this way, I still have a separate issue in
> that
> when two or more services need the certificate for the root domain, they'll
> end
> up sharing it, and I'm unclear what the right way to fix that problem is. If
> it's only services in the base system, that's one thing. But Prosody also has
> this issue with the way I set it up. Currently it's configured so that
> usernames
> can be in the form "u...@example.com" rather than "u...@xmpp.example.com"
> (similar to how email usernames use the root domain). This means it needs the
> certificate for the root domain so that authentication can take place over
> TLS,
> and that breaks the separation.
you can just issue multiple certificates. A compromised prosody would
still be able to leak the certificate for "example.com", but there's
no other way around it as it needs the certificate.
> For some services, it can make sense to use relayd(8) and let that handle TLS
> instead, which simplifies things since relayd has proper privilege separation
> and can even use SNI. But I'm unsure how this could be done with something
> like
> Prosody since XMPP uses STARTTLS (outside of exceptions to that rule like
> XEP-0368).
>
> What can I do to manage this better? Any ideas/suggestions are very welcome.
> Thank you for reading all of this if you made it here.
Can only speak for prosody as it's the only non-base daemon I'm
getting TLS certificates for; my strategy with it has been to generate
a different certificate and to deliver it in a place where only
prosody can read it. Luckily, the prosody package installs
/etc/prosody/certs owned by _prosody alone.
# /etc/acme-client.conf
domain xmpp {
domain name example.com
alternative names { room.example.com upload.example.com }
domain key "/etc/prosody/certs/example.com.key"
domain full chain certificate
"/etc/prosody/certs/example.net.crt"
sign with letsencrypt
}
note the `domain' name is "xmpp" because I have another `domain' block
for the same domain (but different alt names) for httpd:
# only for httpd
domain example.com {
alternative names { www.example.com }
...
}
all handled by cron as usual:
~ * * * * acme-client example.com && rcctl reload httpd
~ * * * * acme-client xmpp && rcctl restart prosody
in prosody.conf.lua i have
certificates = "certs"
I also have some symlinks in /etc/prosody/certs in the form:
{room,uplo
