New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Let's Encrypt Support #1257

Open
jordan-wright opened this Issue Oct 29, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@jordan-wright
Copy link
Collaborator

jordan-wright commented Oct 29, 2018

This is an RFC for a feature idea. Tl;dr I'd like to add Let's Encrypt support to Gophish.

How Certificates Are Handled Right Now

When Gophish is started, two webservers are created: a phishing server and an admin server. By default, Gophish configures the admin server to use a self-signed certificate that is created when the server first starts. The phishing server is started with TLS disabled, since having phishing pages served using a self-signed certificate is less-than-ideal.

If a user obtained a key/certificate from a trusted CA, Gophish allows these to be specified in the config.json and they'll be used on the server. More information can be found in our documentation.

The Problem

The way things are set up now works, but there are a couple of problems:

  • No support for multiple certificates - Right now, Gophish only supports one key/certificate, making it difficult to front multiple domains. This is a highly requested feature.
  • Extra steps to get up and running - Having a valid certificate should be a common deployment. But, we're introducing extra steps, requiring the user to either hunt down or obtain a certificate from their CA. This conflicts with my philosophy that Gophish should "just work".

Introducing Lets Encrypt

Let's Encrypt is a trusted CA sponsored by major companies to provide free TLS certificates in an automated way. Some users have manually setup Let's Encrypt for use with Gophish, which is super cool!

My goal here is to support Let's Encrypt natively. This will make it so that trusted TLS certificates are obtained and used automatically. There is an autocert package that makes integrating Let's Encrypt into a Golang application pretty straightforward, so we'd likely use that.

Open Questions

This approach should help quite a bit, but there are some open questions I'll need to think through:

  • How do we translate this to the config.json without being overwhelming?
  • How do we handle cases where a domain isn't obtained and an IP address is used instead? Should we just create a self-signed certificate in that case?
  • Can we tell Let's Encrypt which hosts we want certificates for dynamically? We don't know what hosts we want when the server starts, but rather when the requests are first received.

As always, I'm open to hearing any feedback on how y'all would want this to work 😄

@jordan-wright jordan-wright added the rfc label Oct 29, 2018

@mcvic1rj

This comment has been minimized.

Copy link

mcvic1rj commented Nov 7, 2018

Should this be handled with the Wildcard/san support in LetsEncrypt? That would let one have up to 100 domains
I would see the config.json having two new arrays called domains under admin_server and phish_server. On start up or what ever period necessary, Gophish will request 2 certificates that contain the domains listed.

The other benefit of going this route is you end up not worrying about a ratelimit so much if someone hits your Gophish server with a malformed/random sni/host header

@jordan-wright

This comment has been minimized.

Copy link
Collaborator

jordan-wright commented Nov 7, 2018

This is a great question!

Unfortunately, the autocert package doesn’t support the creation of wildcard certificates. When I write up the docs, I’ll show two methods of Let’s Encrypt deployment - using it natively to get the certs or generating the certs outside of Gophish and pointing Gophish to them a la how some blogs show it done now.

The question about domains is an interesting one. One thing I’ve been strongly considering is making URLs a first class citizen in Gophish and having them be managed in the database- similar to groups, or templates.

If I did this, I’d have a dynamic whitelist of valid domains. This would prevent a restart anytime a new domain was added, make it easier to type in URLs when building campaigns (since itd be a drop down) and still prevent let’s encrypt requests from being sent out for bad hostnames.

Does that sound like a reasonable approach?

@mcvic1rj

This comment has been minimized.

Copy link

mcvic1rj commented Nov 7, 2018

I think that would work.

I really do like the idea of URLs becoming first class citizens. I know one of the biggest gotcha points I have with creating domains is fat fingering a URL.

The one thing this does not address is what happens with the config.json. Specifically the admin server. Should the call just be made that the admin server and the phish server will use the same certs and domains, just different ports?

@jordan-wright

This comment has been minimized.

Copy link
Collaborator

jordan-wright commented Nov 7, 2018

Should the call just be made that the admin server and the phish server will use the same certs and domains, just different ports?

Yes, this will have to be the case. I don't think it will be possible to have separate certificates for the admin and phishing servers.

@securitygeneration

This comment has been minimized.

Copy link

securitygeneration commented Nov 19, 2018

Will we ever be able to host multiple certs to accommodate multiple campaign domains? Or is the only solution a single cert containing each of the domains we wish to use?

@mcvic1rj

This comment has been minimized.

Copy link

mcvic1rj commented Nov 19, 2018

@securitygeneration I believe this can be handled currently using a SAN certificate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment