Provide self-signed certificate to quickly deploy a test instance of Authelia

[AnalogJ]

Hi,
I'm attempting to setup Authelia on my home server and I'm not being correctly redirected to my service after successfully logging in.
I've traced the Required level for the URL http://droppy.myserver.lan/ is 1 message back to the following lines in the code:

authelia/internal/handlers/handler_firstfactor.go

Lines 125 to 135 in e6ddedf

	ctx.Logger.Debugf("Required level for the URL %s is %d", targetURL.String(), requiredLevel)
	safeRedirection := isRedirectionSafe(*targetURL, ctx.Configuration.Session.Domain)
	if safeRedirection && requiredLevel <= authorization.OneFactor {
	ctx.Logger.Debugf("Redirection is safe, redirecting...")
	response := redirectResponse{bodyJSON.TargetURL}
	ctx.SetJSONBody(response)
	} else {
	ctx.ReplyOK()
	}

Which I then followed to

authelia/internal/handlers/safe_redirection.go

Lines 8 to 17 in 3b2d733

	func isRedirectionSafe(url url.URL, protectedDomain string) bool {
	if url.Scheme != "https" {
	return false
	}
	if !strings.HasSuffix(url.Hostname(), protectedDomain) {
	return false
	}
	return true
	}

It doesn't seem possible to redirect back to non-http urls. Is there a configuration option I'm missing, or am I S.O.L?

[mattgagliardi]

Coincidentally...same issue/question here. TIA!

[james-d-elliott]

Hi @AnalogJ and @mattgagliardi. This is intended functionality. The Authelia cookie could be theoretically used to bypass any authentication. So if transmitted over plain-text connections, it would compromise security. See: https://github.com/authelia/authelia/blob/master/docs/security.md#protection-against-cookie-theft

Edit: Also the cookie cannot be sent over plain-text currently due to the cookie secure attribute.

Combining this with reverse proxies and services like Let's Encrypt, it makes a lot of sense. It may help if you have a specific reason/use case you cannot use Let's Encrypt to secure your service, so that we have an intended outcome.

@clems4ever would best be able to answer this question I believe. There may be scope to make this an option in the future with appropriate justification and thought. For example if we implemented something like #595 we could enforce this validity check.

[mattgagliardi]

@james-d-elliott thanks for clearing up that this is intended, the reasons stated are of course more than valid. FWIW my deployment is in a POC/lab environment...not anything where I'd typically take the time/effort to implement end-to-end encryption, etc. FWIW I've got little experience (only with CertBot) with Let's Encrypt but my recollection is that it's only workable in publicly-exposed environments (or those than can be temporarily exposed publicly...which this can't). So it may be off to the land of self-signed certs. for me.

[james-d-elliott]

With certbot you can obtain the cert and move/copy it. So if you have one publicly facing (for the certbot request) you can then move it where you want. Additionally lets say you own example.com, and example.com/www.example.com points to a publicly facing server, if you also point x.example.com to the same server, in your certbox request if you do "-d example.com -d www.example.com -d x.example.com", you will get a cert that covers all three domains.

[mattgagliardi]

Thanks for the pointer @james-d-elliott, I may give that a run next time. FWIW I went ahead and just generated a fresh self-signed wildcard for my lab and now I'm rolling along just fine. Thanks again!

[clems4ever]

Hello, this issue has already been raised here: #408. After second thought, it brings a lot of security concerns that we'll need to take care of if we implement for just avoiding a cert generation in test/development phase.

The concerns are at least but the list might not be exhaustive:

• are cookie flags ok.
• is redirection safe (at multiple stage depending on the access control policy).

What I propose is instead to provide a self-signed certificate somewhere so that users don't need to generate one. We could also provide the command to generate one in the documentation.