While it is not generally advisable to allow users to freely access sites with bad certificates (expired, self-signed, unknown authorities, common name mismatch, etc) the flexibility of the MWG rule engine does allow you to block on some types of errors, warn on others and allow on others with extensive logging when they click through the warning. It is highly recommended that regardless of category decryption should be performed whenever a certificate error is encountered. The attached rulesets allow the connection to be established, decrypted, and logged whenever a certificate verification error is encountered. It also demonstrates how to implement end user warnings that are customized for your environment. The ruleset includes rules for logging only, blocking and logging and Warn and log. One ruleset replaces the Certificate Verification rules, another is inserted in the URL filter ruleset and the last goes in the log handler rulesets. The Certificate verification rulesets and Logging rulesets combine the functionality described in the comments of this discussion:
Certificate Verification Ruleset:
To warn users and allow click through use this ruleset with the "Log" rule enabled for the types of errors you want to warn
Enable the appropriate rulesets to match errors that you want to warn rather than just log. Each error type has its own coaching config as you may want to set your timeouts differently based on the type of error. If you want to log all accesses after a click through enable the second rule in each coaching ruleset
SSL Incident Log Handler Ruleset:
Writes SSL Incident log on any SSL Incident
Some quick feedback/comments...
In general, if a certificate is self-signed, the issuing CA will be unknown and therefore, by definition, untrusted.
Given a self-signed certificate, a log entry will be written for each reason until a block rule is reached. In other words, if the relevant rules before UntrustedCA have action = continue, then 3 log lines will be created: SelfSigned, UnknownCA and UntrustedCA. Alternately, if SelfSigned has action = block, then UnknownCA and UntrustedCA will never be logged.
If the server certificate isn't self-signed, but the issuing CA is unknown, it will always be untrusted since it has to be known in order to be trusted. The previous log entry concept is also applicable.
Good points and feedback. The reason for continue rather than block in the verification ruleset is to allow coaching/warning of the end user. Unless I am mistaken, if you block during certificate verification, there is no opportunity to provide a warning with a click through option.
The logging for Cert Verification only happens in the log handler so there will be only one entry per certverify, even if the action is continue. However depending on the rules that single entry will have either the last violation that was continued, or the one that had a block action.
Right-- using continue facilitates allowing a click-through after providing a warning to the client. (My comments are based on my experience with doing something very similar...)
One thing that you could do is stack the CertReason data and then have a single logging rule that will fire if User-Defined.SSLIncident = true.
Rule1: cert is self signed --> User-Defined.CertReason = "SelfSigned" / User-Defined.SSLIncident = true
Rule2: cert has unknown CA --> User-Defined.CertReason = User-Defined.CertReason + "UnknownCA" / User-Defined.SSLIncident = true
Rule3: cert has untrusted CA --> User-Defined.CertReason = User-Defined.CertReason + "UntrustedCA"/ User-Defined.SSLIncident = true
Rule4: User-Defined.CertProblem = true -> write log line
Some fiddling with the reason field will probably be necessary in order to make it so that you don't end up with a reason that looks like: "SelfSignedUnknownCAUntrustedCA"
Something like this could work:
Rule1: cert is self signed --> User-Defined.CertReason = ":elfSigned" / User-Defined.SSLIncident = true
Rule2: cert has unknown CA --> User-Defined.CertReason = User-Defined.CertReason + "::UnknownCA" / User-Defined.SSLIncident = true
Rule3: cert has untrusted CA --> User-Defined.CertReason = User-Defined.CertReason + "::UntrustedCA"/ User-Defined.SSLIncident = true
Rule4: User-Defined.SSLIncident = true -> write log line with CertReason::User-Defined.CertReason
That would give you CertReason:elfSigned::UnknownCA::UntrustedCA in the log line.
Depending on an entity's user-base/business/focus, the number of self-signed and/or expired certificates on "mission-critical" websites may result in a need for a coaching implementation. Coaching multiple times for essentially the same reason annoys folks being coached...and doesn't necessarily behave well itself, so my recommendation would be to add up the reasons for the certificate problem and then present a single coaching page/option.
Excellent thoughts. Not sure when I'll get to it. My thinking was that you might want to have different timeouts for different types of cert errors, and I didn't think that it would be a good thing if a user was allowed to click through an expired cert, then they would also be allowed to access a common name mismatch, or self signed cert without prompt. Again, don't know when I'll have the opportunity to look at this further. The feedback is greatly appreciated.
I figure that even if you don't have time to look at this again in the near future, the info may be useful for others.
I classified certificate errors into two groups with corresponding rule sets.
- Group One: Never coach (revoked, for example)
- Various specific SSL inspection whitelisting rules
- Group Two: Offer coaching
For the ones where coaching is offered, I use PDStorage to save the certificate hash value so that acknowledging the coaching for one site that has a self-signed [or other problem] certificate doesn't mean that coaching will be skipped if a different site with the same issue is subsequently encountered.
Even places that should know better have expired certs. Example: https://eca-dsgw.orc.com/dsgw/bin/search?context=eca