Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Is there a way to prevent SSL requests falling back to an unrelated cert? #138

Closed
far-blue opened this issue Aug 10, 2016 · 11 comments
Closed

Is there a way to prevent SSL requests falling back to an unrelated cert? #138

far-blue opened this issue Aug 10, 2016 · 11 comments
Labels
enhancement
Milestone
1.3

Comments

@far-blue
Copy link

I'm playing with vault certs and I've noticed that if I've only supplied SSL certs for some of the hosts fabio is proxying then those without certs can still be served via the HTTPS proxy but will serve with one of the other host's SSL certs. I'm not sure of which one is picked but I guess it might be the first or last one fabio loads from vault.

I'd prefer not to serve invalid certs for services, even accidentally, so is there an option to reject the connection if there is no matching cert?
@magiconair
Copy link
Contributor

The current behavior is to serve the first certificate if none matched since this matches the TLS behavior of the Go stdlib. I can add that. Shouldn't be difficult.

@magiconair
Copy link
Contributor

@far-blue I am wondering whether the fallback option is a property of the cert source (proxy.cs) or the listener (proxy.addr)? And also, whether it should be fallback with default true or nofallback with default false. Do you have an opinion?

@far-blue
Copy link
Author

I would say it's prob. a property of the listener as the cert source is all about fetching certs while the listener is all about serving them. I'd prob. opt for fallback defaulting to true. I'm not keen on double-negatives (we have a few in our legacy codebase and they just cause you to stop and have to think more!) :)

@magiconair
Copy link
Contributor

magiconair commented Aug 30, 2016 •
edited
Loading

@far-blue I tend to agree on both. The only issue with fallback is that now you have to set it everywhere in the code to get the default behavior which goes against the idea that empty structs should be useful and should encode the default behavior.

I can't think of a better name which expresses this in a different way. exactmatch does not capture it and would also need a reference to the certificate matching if configured in the context of the listener. What would this mean?

proxy.addr=:443;cs=demo;exactmatch=false

@far-blue
Copy link
Author

well, if you are talking about the code vs the config, you could present the config as fallback with a default of true but internally represent it as something else such as strictMatch with a default of false. Or you could have something like preventfallback with a default of false if you don't like inverting a config value in code.

@magiconair
Copy link
Contributor

I like strictmatch. No negative logic but still a default value of false.

magiconair added a commit that referenced this issue Aug 30, 2016
@magiconair
Issue #138: Add option to disable cert fallback
6d9a165 
The default behavior of the Go TLS server implementation
is to fall back to the first provided certificate if no
exact matching certificate could be found. It can be
desirable to disable this behavior to have more control
over when a TLS connection is established. This patch
adds a 'strictmatch' option to the listener which allows
to disable the default fallback behavior.

TODO(fs): need test for new getCertificate() function
@magiconair
Copy link
Contributor

Still need to add a test for getCertificate() which does the actual work but that patch should do the trick.

@magiconair
Copy link
Contributor

@far-blue thx for your help

magiconair added a commit that referenced this issue Aug 30, 2016
@magiconair
Issue #138: Add option to disable cert fallback
9afebe8 
The default behavior of the Go TLS server implementation
is to fall back to the first provided certificate if no
exact matching certificate could be found. It can be
desirable to disable this behavior to have more control
over when a TLS connection is established. This patch
adds a 'strictmatch' option to the listener which allows
to disable the default fallback behavior.
magiconair added a commit that referenced this issue Aug 30, 2016
@magiconair
Issue #138: Add option to disable cert fallback
1504735 
The default behavior of the Go TLS server implementation
is to fall back to the first provided certificate if no
exact matching certificate could be found. It can be
desirable to disable this behavior to have more control
over when a TLS connection is established. This patch
adds a 'strictmatch' option to the listener which allows
to disable the default fallback behavior.
@magiconair
Copy link
Contributor

I'll sleep over the strictmatch name and if nothing comes up I'll merge that tomorrow or the day after.

magiconair added a commit that referenced this issue Aug 31, 2016
@magiconair
Issue #138: Add option to disable cert fallback
80cfe2f 
The default behavior of the Go TLS server implementation
is to fall back to the first provided certificate if no
exact matching certificate could be found. It can be
desirable to disable this behavior to have more control
over when a TLS connection is established. This patch
adds a 'strictmatch' option to the listener which allows
to disable the default fallback behavior.
@magiconair
Copy link
Contributor

Merged to master.

@far-blue
Copy link
Author

great! thanks :)

@magiconair magiconair added this to the 1.3 milestone Sep 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
1.3
Development

No branches or pull requests
2 participants
@magiconair @far-blue