Re: acme-client(1) and http_proxy

[Stuart Henderson]

On 2017-04-26, Predrag Punosevac  wrote:
> Adam Thompson wrote:
>
>> I stand by my statement that just buying a cheap SSL cert will, for 
>> anything other than the simple case of an online, directly-connected, 
>> webserver, be cheaper than the labour required to obtain a LetsEncrypt
>> certificate.
>
> A cheap certificate like the one you can buy from GoDaddy will trigger
> browser exception warning just like the self-signed certificates.

They all work just as well as each other unless you have requirements to
support unusual/old clients. Just make sure your server has any necessary
chain certificates as well as the server certificate. Run the ssllabs
checker after setting up (or try connecting with a command-line client),
some browsers hide this problem.

GoDaddy are about 10x too expensive, try ssls.com

Re: acme-client(1) and http_proxy

[Theo de Raadt]

> acme.sh does not require root/sudoer access.  For sure I run it as an 
> unprivileged user and hope you do as well!

The concept of privsep isn't about running as an unprivileged user.

It is so much more.

The problem is that unprivileged users still have the full system call
interface available to them.  Ignoring that reality -- in these trying
times -- is like living in a cave.

Don't care where you run such software.  But suggesting it to others
as a quality choice is irresponsible.

Re: acme-client(1) and http_proxy

[Jeff Ross]

On 4/26/17 12:41 PM, Theo de Raadt wrote:


I haven't seen anyone mention acme.sh yet--a shell script for
letsencrypt with no external dependencies.

https://github.com/Neilpang/acme.sh

No external dependencies, and no security foundations.

No privsep, no clear seperation.

Using pretty much every unsafe pattern tied to security holes in the past.

Using the openssl command *GO READ THAT CODE SOMETIME*, don't go read
the libressl one, go read upstream openssl command source.

No attempt at security.

Just doing the job, and assuming every mistake later can be

It's like constructing jetliners from foundational components, and by
that I mean sticks and stones.

I'm sorry, but I don't get it.  It is crazy to recommend something
that hasn't been STUDIED to ensure it dutifully tries to only perform
the task and creates no new risk.


Always good to hear from you, Theo!

acme.sh does not require root/sudoer access.  For sure I run it as an 
unprivileged user and hope you do as well!


Jeff

Re: acme-client(1) and http_proxy

[Theo de Raadt]

> I haven't seen anyone mention acme.sh yet--a shell script for 
> letsencrypt with no external dependencies.
> 
> https://github.com/Neilpang/acme.sh

No external dependencies, and no security foundations.

No privsep, no clear seperation.

Using pretty much every unsafe pattern tied to security holes in the past.

Using the openssl command *GO READ THAT CODE SOMETIME*, don't go read
the libressl one, go read upstream openssl command source.

No attempt at security.

Just doing the job, and assuming every mistake later can be  

It's like constructing jetliners from foundational components, and by
that I mean sticks and stones.

I'm sorry, but I don't get it.  It is crazy to recommend something
that hasn't been STUDIED to ensure it dutifully tries to only perform
the task and creates no new risk.

Re: acme-client(1) and http_proxy

[Jeff Ross]

On 4/26/17 11:02 AM, Stuart Henderson wrote:


On 2017-04-25, Adam Thompson  wrote:

On 2017-04-25 05:27, Stuart Henderson wrote:


* If you want to do dns-01 challenge with acme-client, you'll need to
use Kristaps' version for now, base acme-client only supports the
standard http challenge type. The UI isn't the simplest; use
'-t dns-01', then it outputs "dns-01 domainname token.key", then
you convert token.key into a suitable format for a DNS TXT record:
   "echo -n token.key | sha256 -b | tr -d = | tr + - | tr / _"
Get the record to the nameserver, then send the whole "dns-01
domainname token.key" line back to acme-client, and cross fingers.
If there are too many errors you'll lock yourself out for a period,
so test with the staging server first.


I haven't seen anyone mention acme.sh yet--a shell script for 
letsencrypt with no external dependencies.


https://github.com/Neilpang/acme.sh

It was trivial for me to write a dns api script for djbdns--very handy 
to have to bootstrap a new domain without previously setting up http in 
apache2 first.


I'd send that out to anyone interested--ask me off list.

Jeff

Re: thank you sthen@ [Was: Re: acme-client(1) and http_proxy]

[Stuart Henderson]

On 2017-04-26, Marcus MERIGHI  wrote:
> To keep him going I suggest:
>
> http://spacehopper.org/wishlist
>
> "Exploding the phone" is taken.
> ("Estimated delivery:  23 May 2017 - 16 Jun. 2017")
>
> We all benefit :-)

Thanks!  I haven't updated that list recently so it's a bit random at the 
moment :-)

Re: acme-client(1) and http_proxy

[Stuart Henderson]

On 2017-04-25, Adam Thompson  wrote:
> On 2017-04-25 05:27, Stuart Henderson wrote:
>
>> Firstly, with dns-01 challenge you can get a certificate for a server
>> which doesn't allow external access at all (the request and challenge
>> can be done with completely separate machines than the certificate
>> is for).
>> 
>> Secondly, some environments permit inbound connections but require
>> a proxy for outbound access from a DMZ. In a hosting environment,
>> restricting outbound access is often more important than inbound.
>
> While it's possible that this was the case, the fact the OP was even 
> asking the question in the first place strongly suggests that this is 
> not his situation.
>
> I stand by my statement that just buying a cheap SSL cert will, for 
> anything other than the simple case of an online, directly-connected, 
> webserver, be cheaper than the labour required to obtain a LetsEncrypt 
> certificate.
>
>  From what I've read so far, you'd have to be *really* committed to 
> LetsEncrypt to go to the bother of using any of the alternate challenge 
> protocols.

It's not that hard with some clients, especially with DNS hosted at
a provider that has an API that the client already supports (or with
nsupdate).

If it's a one-off, I agree a cheap SSL cert is often easier. But the
work that's involved is manual and needs doing at renewal (generate
key/csr, get payment approval, login to CA's website, order, enter
card details, manually handle CA's DNS/email auth, copy cert into
place, figure out which chain certs are needed if the CA changed
them, fix things if you messed up with the keys). Multiply that by
a few domains, especially when they need renewing at different
times, and it gets to be a real pain. More so when browsers push
harder and the validity of certs gets reduced in length across the
board.

So with LetsEncrypt and especially non-http challenges it's often
more of a faff to setup initially, but that's once only, amortised
across multiple domains, in theory the only thing you're likely to
need to do later is update the agreement URL.

(And you don't have to worry about unscrupulous registrars trying
to rip you off by autorenewing at several times the usual cost,
hi g*d***y).

> In all the situations where one person could complete the 
> process themselves, that person is highly likely to simply be directly 
> connected anyway - so why bother?

I usually only let webservers connect out to specific IPs, which doesn't
work for connecting to letsencrypt's API servers, currently on akamai
and moving around. Punting the requests to a proxy lets you to restrict
by domain name on the proxy instead.

> Once the entire CA industry moves towards ACME (if that happens) then I 
> can see a number of situations where those alternate challenge protocols 
> will be useful and/or required, but for a LetsEncrypt certificate?  It 
> just doesn't seem worthwhile.  Especially when the cost of a 
> single-hostname SSL cert (which meets the needs of many users) is now 
> somewhere below US$5/year!
>
> And neither of us addressed the fact that for a server that's "behind a 
> corporate firewall", there's a good chance that it's not even using a 
> legit gTLD/ccTLD, which means getting an external domain-validated SSL 
> cert for it will be (or should be!) impossible in the first place.

It may well be "www.$somecompany.com" on a DMZ behind a corporate
firewall.

And/or it may be run on multiple machines for failover and need the
cert on all of them, here it's often more straightforward to do
the auth from a management host (dns challenge is really needed for
this) and push out the cert and keys across from config management.



* If you want to do dns-01 challenge with acme-client, you'll need to
use Kristaps' version for now, base acme-client only supports the
standard http challenge type. The UI isn't the simplest; use
'-t dns-01', then it outputs "dns-01 domainname token.key", then
you convert token.key into a suitable format for a DNS TXT record:
  "echo -n token.key | sha256 -b | tr -d = | tr + - | tr / _"
Get the record to the nameserver, then send the whole "dns-01
domainname token.key" line back to acme-client, and cross fingers.
If there are too many errors you'll lock yourself out for a period,
so test with the staging server first.

thank you sthen@ [Was: Re: acme-client(1) and http_proxy]

[Marcus MERIGHI]

To keep him going I suggest:

http://spacehopper.org/wishlist

"Exploding the phone" is taken.
("Estimated delivery:  23 May 2017 - 16 Jun. 2017")

We all benefit :-)

Marcus

stefan.wol...@web.de (Stefan Wollny), 2017.04.26 (Wed) 10:04 (CEST):
> Gesendet:??Mittwoch, 26. April 2017 um 06:16 Uhr
> Von:??"Predrag Punosevac" <punoseva...@gmail.com>
> An:??misc@openbsd.org
> Betreff:??Re: acme-client(1) and http_proxy
> [ ... ]
> > Best,
> > Predrag
> > 
> > P.S. In all my years on this mailing list I have seen nothing but the
> > most insightful, helpful, and polite answers by Mr. Stuart Henderson.
> +1
> 
> > If he had labeled my post as a "Fake news :)" I would reflect on it
> > before posting again in the same thread.
> Words of wisdom here
> 
> !DSPAM:590054a628014500718621!

Re: acme-client(1) and http_proxy

[Stefan Wollny]

Gesendet: Mittwoch, 26. April 2017 um 06:16 Uhr
Von: "Predrag Punosevac" <punoseva...@gmail.com>
An: misc@openbsd.org
Betreff: Re: acme-client(1) and http_proxy
[ ... ]
> Best,
> Predrag
> 
> P.S. In all my years on this mailing list I have seen nothing but the
> most insightful, helpful, and polite answers by Mr. Stuart Henderson.
+1

> If he had labeled my post as a "Fake news :)" I would reflect on it
> before posting again in the same thread.
Words of wisdom here

Re: acme-client(1) and http_proxy

[Predrag Punosevac]

Adam Thompson wrote:

> I stand by my statement that just buying a cheap SSL cert will, for 
> anything other than the simple case of an online, directly-connected, 
> webserver, be cheaper than the labour required to obtain a LetsEncrypt
> certificate.

A cheap certificate like the one you can buy from GoDaddy will trigger
browser exception warning just like the self-signed certificates. If the
your goal is to encrypt web traffic self-signed certificate will do it.
If your goal is to provide a peace of mind to your customers by
presenting them a proper SSL certificate which will authenticate against
credible third party server I am afraid that you will have to shell
little bit more money to get the one from Verisign.

LetsEncrypt is a wonderful option for people like me who need to have
both (encryption and authentication) but without resources (working for
an academic Lab) to pay for a real certificate.

Best,
Predrag

P.S. In all my years on this mailing list I have seen nothing but the
most insightful, helpful, and polite answers by Mr. Stuart Henderson.
If he had labeled my post as a "Fake news :)" I would reflect on it
before posting again in the same thread.

Re: acme-client(1) and http_proxy

[Adam Thompson]

On 2017-04-25 05:27, Stuart Henderson wrote:

On 2017-04-25, Adam Thompson  wrote:

By definition, you will (probably) not be able to use the ACME
protocol - it only works (normally) when your system is connected
directly to the public internet with a static IP address.

Simply because you say "behind a corporate firewall", I already know
(or at least assume) that ACME will not work for you, ever.

ACME, and LetsEncrypt, only handles public websites. There are ways
around this, but they are painful and likely not worthwhile - it
*will* be cheaper to just buy a regular SSL certificate than to get a
LetsEncrypt certificate for an internal server.


Fake news :)


Ha!  That made me laugh!
I was deliberately omitting all the details of the other challenge 
protocols, because (see below).  But yes, I deliberately sacrificed 
correctness for utility in my response.



Firstly, with dns-01 challenge you can get a certificate for a server
which doesn't allow external access at all (the request and challenge
can be done with completely separate machines than the certificate
is for).

Secondly, some environments permit inbound connections but require
a proxy for outbound access from a DMZ. In a hosting environment,
restricting outbound access is often more important than inbound.


While it's possible that this was the case, the fact the OP was even 
asking the question in the first place strongly suggests that this is 
not his situation.


I stand by my statement that just buying a cheap SSL cert will, for 
anything other than the simple case of an online, directly-connected, 
webserver, be cheaper than the labour required to obtain a LetsEncrypt 
certificate.


From what I've read so far, you'd have to be *really* committed to 
LetsEncrypt to go to the bother of using any of the alternate challenge 
protocols.  In all the situations where one person could complete the 
process themselves, that person is highly likely to simply be directly 
connected anyway - so why bother?


Once the entire CA industry moves towards ACME (if that happens) then I 
can see a number of situations where those alternate challenge protocols 
will be useful and/or required, but for a LetsEncrypt certificate?  It 
just doesn't seem worthwhile.  Especially when the cost of a 
single-hostname SSL cert (which meets the needs of many users) is now 
somewhere below US$5/year!


And neither of us addressed the fact that for a server that's "behind a 
corporate firewall", there's a good chance that it's not even using a 
legit gTLD/ccTLD, which means getting an external domain-validated SSL 
cert for it will be (or should be!) impossible in the first place.


-Adam

Re: acme-client(1) and http_proxy

[Stuart Henderson]

On 2017-04-25, Adam Thompson  wrote:
> By definition, you will (probably) not be able to use the ACME
> protocol - it only works (normally) when your system is connected
> directly to the public internet with a static IP address.
> 
> Simply because you say "behind a corporate firewall", I already know
> (or at least assume) that ACME will not work for you, ever.
>
> ACME, and LetsEncrypt, only handles public websites. There are ways
> around this, but they are painful and likely not worthwhile - it
> *will* be cheaper to just buy a regular SSL certificate than to get a
> LetsEncrypt certificate for an internal server.

Fake news :)

Firstly, with dns-01 challenge you can get a certificate for a server
which doesn't allow external access at all (the request and challenge
can be done with completely separate machines than the certificate
is for).

Secondly, some environments permit inbound connections but require
a proxy for outbound access from a DMZ. In a hosting environment,
restricting outbound access is often more important than inbound.

Re: acme-client(1) and http_proxy

[Stuart Henderson]

On 2017-04-21, Manuel Giraud  wrote:
> Hi,
>
> I'm trying to use the new acme-client on a server behind a corporate
> proxy (i.e. I have to set a http_proxy to get out). It seems (from
> reading the code) that acme-client(1) does not honor http_proxy.
>
> Is this on purpose? If so, can someone point me to another acme client
> that does this?

Most other acme clients do work through a proxy - use whatever fits your
needs best..

Re: acme-client(1) and http_proxy

[Adam Thompson]

By definition, you will (probably) not be able to use the ACME protocol - it 
only works (normally) when your system is connected directly to the public 
internet with a static IP address.

Simply because you say "behind a corporate firewall", I already know (or at 
least assume) that ACME will not work for you, ever.

ACME, and LetsEncrypt, only handles public websites.  There are ways around 
this, but they are painful and likely not worthwhile - it *will* be cheaper to 
just buy a regular SSL certificate than to get a LetsEncrypt certificate for an 
internal server.

-Adam

> -Original Message-
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On
> Behalf Of Manuel Giraud
> Sent: April 21, 2017 07:37
> To: misc@openbsd.org
> Subject: acme-client(1) and http_proxy
> 
> Hi,
> 
> I'm trying to use the new acme-client on a server behind a corporate
> proxy (i.e. I have to set a http_proxy to get out). It seems (from reading
> the code) that acme-client(1) does not honor http_proxy.
> 
> Is this on purpose? If so, can someone point me to another acme client
> that does this?
> --
> Manuel Giraud