[DRIVERS-2158] Forbid conflicting tlsInsecure options in URI spec Created: 28/Jun/19 Updated: 31/Mar/22 |
|
| Status: | Backlog |
| Project: | Drivers |
| Component/s: | URI Options |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Major - P3 |
| Reporter: | Samuel Rossi (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Driver Changes: | Needed | ||||
| Description |
|
In the URI options spec, we define a few provisions about raising errors when TLS-related options are ambiguous in order to mitigate the risk that a user runs their application with unintended TLS behavior. One of these provisions requires that errors be raised if there are conflicting values for the tls/ssl option. When implementing the spec for C#, Dima pointed out that we don't define a similar provision for if tlsInsecure is provided more than once with conflicting values (and likewise for tlsAllowInvalidHostnames and tlsAllowInvalidCertificates. I think that we should add provisions to the spec indicating that each of these options can't have both true and false set for them if they appear multiple times (using similar language to the provision for tls and ssl. |
| Comments |
| Comment by Samuel Rossi (Inactive) [ 01/Jul/19 ] |
|
Yes, this is specifically related to an existing section in the URI options spec that I'd like to add a couple more clauses to |
| Comment by Ian Whalen (Inactive) [ 01/Jul/19 ] |
|
sam.rossi can you please confirm this is relevant to URI Options (as opposed to connection strings). |
| Comment by Samuel Rossi (Inactive) [ 28/Jun/19 ] |
|
Sounds good! I don't think there's any desire to turn non-TLS related instances of repeated values into errors; we added the existing provisions solely out of security concerns, and the new ones I suggest here are similarly just scoped to instances where I think security concerns are warranted. |
| Comment by Robert Stam [ 28/Jun/19 ] |
|
In the C# driver we have always had the rule that when a key is repeated the last value simply overwrites any earlier values. I was actually unaware that any other driver might do something different, or that the spec said this was unambiguous. It's rather annoying to have to write extra code to detect multiple values (and even slightly tricky since it's not multiple values per se that's specified as invalid, only multiple conflicting values). We will implement the convoluted error checking for tls related options, but will not make any changes to existing options that currently implement last one wins. |