OCSP support for netty-tcnative by rkapsi · Pull Request #215 · netty/netty-tcnative

rkapsi · 2016-12-27T20:03:36Z

OCSP stapling support for netty-tcnative using OpenSSL's tlsext_status API. This is a low-level API and not meant to be used directly. There will be a saparate PR for Netty.

Motivation

OCSP stapling (formally known as TLS Certificate Status Request extension) is alternative approach for checking the revocation status of X.509 Certificates. Servers can preemptively fetch the OCSP response from the CA's responder, cache it for some period of time, and pass it along during (a.k.a. staple) the TLS handshake. The client no longer has to reach out on its own to the CA to check the validity of a cetitficate. Some of the key benefits are:

Speed. The client doesn't have to crosscheck the certificate.
Efficiency. The Internet is no longer DDoS'ing the CA's OCSP responder servers.
Safety. Less operational dependence on the CA. Certificate owners can sustain short CA outages.
Privacy. The CA can lo longer track the users of a certificate.

https://en.wikipedia.org/wiki/OCSP_stapling
https://letsencrypt.org/2016/10/24/squarespace-ocsp-impl.html

Modifications

https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html

Result

Low-level API to enable OCSP stapling

rkapsi · 2016-12-27T20:13:59Z

@normanmaurer @Scottmitch - please take a new look. I hope all requested changes got incorporated in this new PR and I've just pushed a PR for the other side.

netty/netty#6158

Scottmitch · 2016-12-28T18:30:48Z

openssl-dynamic/src/main/c/ocsp.c

+    // are being outputted to STDERR because the calling Thread is not
+    // attached to the JVM yet.
+
+    if (OCSP_CALLBACK_CLAZZ == NULL) {


#201 (comment)

is this check necessary? the CALLBACK_METHOD check should be sufficient right and CALLBACK_CLAZZ is not directly used in this method.

Scottmitch · 2016-12-28T18:38:22Z

openssl-dynamic/src/main/c/ocsp.c

+        return error;
+    }
+
+    if ((*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL) != JNI_OK) {


can you add a comment as to why this is necessary?

Scottmitch · 2016-12-28T18:40:23Z

openssl-dynamic/src/main/c/ocsp.c

+ * Returns true is OCSP stapling is available.
+ */
+TCN_IMPLEMENT_CALL(jboolean, SSLContext, isOcspSupported)(TCN_STDARGS) {
+    return JNI_TRUE;


this should depend upon what options are supported by the dynamically linked OpenSSL library, and potentially the compile version and related flags, right?

The current return true is dependent on the outer #ifdef which says OpenSSL >= 1.0.2 and !defined(OPENSSL_NO_OCSP).

What if we build against 1.0.2 but the user links a 1.0.1? See OpenSsl#isAlpnSupported for a tip

Scottmitch · 2016-12-28T18:41:22Z

openssl-dynamic/src/main/c/ocsp.c

+/**
+ * Installs the OCSP stapling callback.
+ */
+TCN_IMPLEMENT_CALL(jobject, SSLContext, newOcspCallback)(TCN_STDARGS, jlong ctx, jboolean client, jobject callback) {


#201 (comment)

can we just group the code into ssl.c and sslcontext.c instead of introducing new modules? That would be more consistent and helps orient you as to what the scope the methods apply to.

Certainly. Don't know if it's easier to follow. :)

Don't know if it's easier to follow

debatable for sure ... but it is at least consistent with the current approach. @normanmaurer - thoughts?

Scottmitch · 2016-12-28T18:44:36Z

openssl-dynamic/src/main/c/ocsp.c

+
+    if (client) {
+        error = SSL_CTX_set_tlsext_status_cb(c->ctx, netty_ocsp_client_callback);
+


nit: remove line? also consider making this a tertiary statement error = client ? ... : ... ;

Scottmitch · 2016-12-28T18:57:21Z

openssl-dynamic/src/main/c/ocsp.c

+
+    OCSP_CALLBACK_METHOD = (*env)->GetMethodID(env, OCSP_CALLBACK_CLAZZ, "callback", "(J)I");
+    if (OCSP_CALLBACK_METHOD == NULL) {
+        return JNI_ERR;


consider adding a fprintf here. It is not expected to occur frequently, but if it does the additional context should help narrow in on the root cause faster.

This should actually result in a NoSuchMethodError in Java land.

thanks for clarifying ... we rely upon an exception pending and being popped off when we transition from JNI to java.

Scottmitch · 2016-12-28T18:59:29Z

openssl-dynamic/src/main/java/io/netty/tcnative/jni/ocsp/OcspCallback.java

+ * License for the specific language governing permissions and limitations
+ * under the License.
+ */
+package io.netty.tcnative.jni.ocsp;


we are using the new package which the master branch uses. can we open another PR against the master branch, or do we need this in the 1.1.33 branch too? The next release of Netty should move to the master branch of netty-tcnative.

Sooo, on my end we don't need to support "old" versions and we'll use whatever latest SNAPSHOT of Netty is using.

IMO we can just target this at the master branch. @normanmaurer - WDYT?

Went ahead and rebased with master and targeting only master.

Scottmitch · 2016-12-28T19:01:27Z

openssl-dynamic/src/main/java/io/netty/tcnative/jni/ocsp/OcspCallback.java

+ * indicates to OpenSSL what the user did.
+ * 
+ * Client: OpenSSL will call the {@link OcspCallback} during/after the handshake and it's expecting the
+ * user to get the OCSP staple using {@link SSL#getOcspStaple(long)} and tell OpenSSL via the return value


to get -> will get

Scottmitch · 2016-12-28T19:03:11Z

openssl-dynamic/src/main/java/io/netty/tcnative/jni/ocsp/OcspCallback.java

+     * 
+     * NOTE: The user must call {@link SSL#setOcspStaple(long, byte[])} prior to returning this value.
+     */
+    public static final int SSL_TLSEXT_ERR_OK = 0;


if these are server only ... should we include SERVER in the variable name? Same thing for the client only status codes.

Sure, if there are no objections I'd like to name them slightly better altogether. The current names are coming from OpenSSL's own documentation and tls1.h. I don't find them particularly good (at all) but there's maybe value in being able align the Java/C code.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html

I see. I don't think it is necessary to have the Java API be 1 to 1 with the OpenSSL API. However if the values do directly correlate to an OpenSSL value it would be helpful to indicate the relationship somehow (e.g. javadoc, etc..).

Scottmitch · 2016-12-28T19:07:07Z

openssl-dynamic/src/main/java/org/apache/tomcat/jni/SSL.java

+     * @see #TLSEXT_STATUSTYPE_host_name
+     * @see #TLSEXT_STATUSTYPE_ocsp
+     */
+    public static native boolean setStatusType(long ssl, int type);


this method name is relatively generic. can we include Ocsp in the name?

If we don't care about the exact details of SSL_set_tlsext_status_type() we can make it setOcspEnabled(long ssl, boolean enabled)

Scottmitch

I meant to "Request Changes" on the GitHub review instead of "Approve" :)

rkapsi · 2017-02-08T22:49:21Z

@Scottmitch please take a new look.

rkapsi · 2017-02-23T19:11:21Z

@Scottmitch @normanmaurer friendly poke :)

Scottmitch

few comments but general approach lgtm

Scottmitch · 2017-03-02T01:22:18Z

openssl-dynamic/src/main/c/ocsp.c

+#include <stdio.h>
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wunused-variable"


can you explain why this is necessary and add a comment? Is it possible just to fix the warning?

The story goes like this: We're currently using a separate JNI library to implement OCSP and we link it against tcnative. Our security team asked to built it with strict validation and we asked them to set it up. I assume ssl_private.h didn't pass strict validation and that's why they added it.

Now, I just copy & pasted it here without putting much thought into it. It's not needed in this context and we can remove it and do a separate PR for changing compiler flags.

sgtm ... I would prefer to not have this, and just fix the warnings (if any) caused by ssl_private.h

Scottmitch · 2017-03-02T01:23:54Z

openssl-dynamic/src/main/c/ocsp.c

+{
+    return openssl_netty_tcnative_ocsp_callback(TCN_SERVER_CALLBACK_ERROR, ssl, arg);
+}
+#endif


I think this is the end of the !defined(TCN_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL) block ... if so can you modify this to #endif /* !defined(TCN_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL) */

Scottmitch · 2017-03-02T01:27:14Z

openssl-dynamic/src/main/c/ocsp.c

+
+#if !defined(TCN_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL)
+
+#ifndef TCN_CLIENT_CALLBACK_ERROR


is it expected that these defines will be defined outside this scope? Should we more fully qualify these names (e.g. TCN_OCSP_..) and just treat this as an error if there is a duplicate name?

Scottmitch · 2017-03-02T01:31:54Z

openssl-dynamic/src/main/c/ocsp.c

+    int response = 0;
+    jobject callback = (*env)->NewLocalRef(env, (jweak)arg);
+
+    if ((*env)->IsSameObject(env, callback, NULL) == JNI_FALSE) {


since this is designed to be a boolean lets treat it as one -> if (!(*env)->IsSameObject(env, callback, NULL)) { .. }

Scottmitch · 2017-03-02T01:37:14Z

openssl-dynamic/src/main/c/ocsp.c

+        return error;
+    }
+
+    if (OCSP_CALLBACK_CLAZZ == NULL) {


is it necessary to check this here ... can we just fail in the init method if we can't load the class?

Scottmitch · 2017-03-02T02:25:14Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/SSLContext.java

+    /**
+     * Removes and frees the {@link OcspCallback}
+     * 
+     * https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html


make this a hyper link <a href=""></a>

Scottmitch · 2017-03-02T02:25:36Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/SSL.java

+    /**
+     * Enables OCSP stapling on a {@link SSLEngine}.
+     * 
+     * https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html


make this a hyper link <a href=""></a> (general comment)

Scottmitch · 2017-03-02T02:26:54Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/ocsp/OcspCallback.java

+
+/**
+ * Implementations of this interface are being called from JNI for each {@link SSLEngine} instance that
+ * has OCSP stapling enabled. Please notice that it's the same interface for client and server SSL engines


nit: SSL engines -> {@link SSLEngine}s ... or just for client and server mode

Scottmitch · 2017-03-02T02:27:45Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/ocsp/OcspCallback.java

+ * user to get the OCSP staple using {@link SSL#getOcspStaple(long)} and tell OpenSSL via the return value
+ * if it's any good.
+ *
+ * https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html


Scottmitch · 2017-03-02T02:29:49Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/ocsp/OcspCallback.java

+     * 
+     * SSL_TLSEXT_ERR_OK
+     */
+    int OCSP_SERVER_ACK = 0;


we should derive these values from JNI to ensure they remain consistent. See NativeStaticallyReferencedJniMethods

Scottmitch · 2017-03-02T02:30:34Z

also sorry for the delay 😢

Scottmitch · 2017-03-02T02:35:49Z

@rkapsi - Also don't forget to add the new .c file to the vs2010 files [1][2]

[1] https://github.com/netty/netty-tcnative/blob/master/vs2010.vcxproj.static.template
[2] https://github.com/netty/netty-tcnative/blob/master/openssl-dynamic/src/main/native-package/vs2010.vcxproj

Scottmitch · 2017-03-06T23:14:26Z

openssl-dynamic/src/main/c/ocsp.c

+#ifndef TCN_NO_OCSP
+#ifndef OPENSSL_IS_BORINGSSL
+
+#ifndef TCN_OCSP_CLIENT_CALLBACK_ERROR


it doesn't look like these defines are used outside this scope ... if these are already defined wouldn't this be a programming error we want to investigate? Is the intention to allow overriding this as part of the build environment?

Correct, not used outside of this scope and and the only intention is to have two named constants.

so is the #ifdef protection necessary can we do one of the following:

remove the ifdefs

define these values as static const to get type safety

The second approach is preferred if this still satisfies your needs.

Scottmitch · 2017-03-06T23:15:41Z

openssl-dynamic/src/main/c/ocsp.c

+
+#include <stdio.h>
+
+#ifndef TCN_NO_OCSP


consider refactoring to avoid nesting ifdef macros:

#if !defined(TCN_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL)

Scottmitch · 2017-03-06T23:24:58Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/OcspCallbackStatus.java

+    private OcspCallbackStatus() {}
+
+    // ATTENTION: This class is purposely separate from the OcspCallback interface
+    // as JNI will otherwise fail to initialize due to a circular dependencies that


can you explain this comment? The purpose of NativeStaticallyReferencedJniMethods is to avoid circular class loader issues. If this is not the case is something broken?

Sure, these constants lived previously in the OcspCallback interface and the values were hardcoded. It created a circular dependency as soon as I started using NativeStaticallyReferencedJniMethods for pulling the values from JNI.

JNI_OnLoad calls ocsp/init which touches the OcspCallback interface which would call back into JNI before JNI_OnLoad had returned. The JVM failed to load tcnative with a UnsatisfiedLinkError saying something about JVM version 0xFFFFFFFF not being supported.

It created a circular dependency as soon as I started using NativeStaticallyReferencedJniMethods for pulling the values from JNI.

I see. We manually control the class load sequencing in transport-native-epoll [1] to avoid this issue. We should be doing the same in tcnative too ... thx for pointing this out I will add a PR to correct this.

[1] https://github.com/netty/netty/blob/4.1/transport-native-epoll/src/main/c/netty_epoll_native.c#L849

see PR #245

I'll move 'em back into the interface as soon as you merge #245

#245 has been merged

Scottmitch · 2017-03-06T23:32:56Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/OcspCallbackStatus.java

+    public static final int OCSP_SERVER_NACK = sslTlsExtErrAlertWarning();
+
+    /**
+     * SERVER ONLY: Some error occurred. Throwing an {@link Exception} from the {@link #callback(long)}


the callback(long) links in this file are no longer valid.

Scottmitch · 2017-03-06T23:33:58Z

openssl-dynamic/src/main/java/io/netty/internal/tcnative/SSL.java

+     * on success. The {@code byte[]} is assumed to be a valid OCSP staple as provided
+     * to you by the CA's OCSP responder. No further validation will be applied and
+     * incorrect data will likely result in a drop of the underlying connection.
+     *


add a <p> in here?

rkapsi · 2017-03-09T17:02:57Z

openssl-dynamic/src/main/c/ocsp.c


 #elif defined(OPENSSL_IS_BORINGSSL)
-    const *uint8_t value = OPENSSL_malloc(sizeof(uint8_t) * length);
+    const uint8_t *value = OPENSSL_malloc(sizeof(uint8_t) * length);


This faux pas went unnoticed because BoringSSL compiles with OPENSSL_NO_OCSP.

Scottmitch

sounds like we need to adjust the defines to accommodate for boringssl?

Scottmitch · 2017-03-09T17:54:00Z

openssl-dynamic/src/main/c/ocsp.c

+        return;
+    }
+
+#if defined(OPENSSL_NO_OCSP)


based upon netty/netty#6158 (comment) ... should we only check OPENSSL_NO_OCSP if !defined(OPENSSL_IS_BORINGSSL)?

so the simplistic approach I had in mind is:

#if defined(OPENSSL_NO_OCSP) -> #if defined(OPENSSL_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL)

We may be able to refactor the macros a bit but basically if OPENSSL_IS_BORINGSSL == true we should just ignore OPENSSL_NO_OCSP and use the BoringSSL APIs.

diff --git a/openssl-dynamic/src/main/c/ocsp.c b/openssl-dynamic/src/main/c/ocsp.c index 317490e..f625817 100644 --- a/openssl-dynamic/src/main/c/ocsp.c +++ b/openssl-dynamic/src/main/c/ocsp.c @@ -54,7 +54,7 @@ TCN_IMPLEMENT_CALL(void, SSLContext, enableOcsp)(TCN_STDARGS, jlong ctx, jboolea return; } -#if defined(OPENSSL_NO_OCSP) +#if defined(OPENSSL_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL) tcn_ThrowException(e, "netty-tcnative was built without OCSP support"); #elif defined(TCN_OCSP_NOT_SUPPORTED) @@ -107,7 +107,7 @@ TCN_IMPLEMENT_CALL(void, SSL, enableOcsp)(TCN_STDARGS, jlong ssl) { return; } -#if defined(OPENSSL_NO_OCSP) +#if defined(OPENSSL_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL) tcn_ThrowException(e, "netty-tcnative was built without OCSP support"); #elif defined(TCN_OCSP_NOT_SUPPORTED) @@ -139,14 +139,14 @@ TCN_IMPLEMENT_CALL(void, SSL, setOcspResponse)(TCN_STDARGS, jlong ssl, jbyteArra return; } -#if defined(OPENSSL_NO_OCSP) +#if defined(OPENSSL_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL) tcn_ThrowException(e, "netty-tcnative was built without OCSP support"); #elif defined(TCN_OCSP_NOT_SUPPORTED) tcn_ThrowException(e, "OCSP stapling is not supported"); #elif defined(OPENSSL_IS_BORINGSSL) - const uint8_t *value = OPENSSL_malloc(sizeof(uint8_t) * length); + uint8_t *value = OPENSSL_malloc(sizeof(uint8_t) * length); if (value == NULL) { tcn_ThrowException(e, "OPENSSL_malloc() returned null"); return; @@ -192,7 +192,7 @@ TCN_IMPLEMENT_CALL(jbyteArray, SSL, getOcspResponse)(TCN_STDARGS, jlong ssl) { return NULL; } -#if defined(OPENSSL_NO_OCSP) +#if defined(OPENSSL_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL) tcn_ThrowException(e, "netty-tcnative was built without OCSP support"); #elif defined(TCN_OCSP_NOT_SUPPORTED)

Scottmitch

1 more comment ... and the c89 compatibility question for @normanmaurer then lgtm

Scottmitch · 2017-03-09T22:44:28Z

pom.xml

    <aprVersion>1.5.2</aprVersion>
    <aprMd5>98492e965963f852ab29f9e61b2ad700</aprMd5>
-    <boringsslBranch>chromium-stable</boringsslBranch>
+    <boringsslBranch>master</boringsslBranch>


you can revert this change bcz the changes we need have been released

…s API. This is a low-level API and not meant to be used directly. There will be a saparate PR for Netty. Motivation OCSP stapling (formally known as TLS Certificate Status Request extension) is alternative approach for checking the revocation status of X.509 Certificates. Servers can preemptively fetch the OCSP response from the CA's responder, cache it for some period of time, and pass it along during (a.k.a. staple) the TLS handshake. The client no longer has to reach out on its own to the CA to check the validity of a cetitficate. Some of the key benefits are: 1) Speed. The client doesn't have to crosscheck the certificate. 2) Efficiency. The Internet is no longer DDoS'ing the CA's OCSP responder servers. 3) Safety. Less operational dependence on the CA. Certificate owners can sustain short CA outages. 4) Privacy. The CA can lo longer track the users of a certificate. https://en.wikipedia.org/wiki/OCSP_stapling https://letsencrypt.org/2016/10/24/squarespace-ocsp-impl.html Modifications https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html Result Low-level API to enable OCSP stapling

rkapsi · 2017-03-23T13:51:32Z

@Scottmitch poke - both PRs are ready in case you missed the Github emails. Commits are squashed and ocsp.c has has been folded into ssl.c and sslcontext.c.

Scottmitch

lgtm ... sorry for the delay 😢

Scottmitch · 2017-03-28T17:20:05Z

master (1e77375)

normanmaurer · 2017-03-28T17:22:58Z

+1 ... Thanks @Scottmitch for taking care and @rkapsi for the work !

netty/netty-tcnative#215 Motivation OCSP stapling (formally known as TLS Certificate Status Request extension) is alternative approach for checking the revocation status of X.509 Certificates. Servers can preemptively fetch the OCSP response from the CA's responder, cache it for some period of time, and pass it along during (a.k.a. staple) the TLS handshake. The client no longer has to reach out on its own to the CA to check the validity of a cetitficate. Some of the key benefits are: 1) Speed. The client doesn't have to crosscheck the certificate. 2) Efficiency. The Internet is no longer DDoS'ing the CA's OCSP responder servers. 3) Safety. Less operational dependence on the CA. Certificate owners can sustain short CA outages. 4) Privacy. The CA can lo longer track the users of a certificate. https://en.wikipedia.org/wiki/OCSP_stapling https://letsencrypt.org/2016/10/24/squarespace-ocsp-impl.html Modifications https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html Result High-level API to enable OCSP stapling

rkapsi mentioned this pull request Dec 27, 2016

OCSP stapling support for Netty using netty-tcnative. netty/netty#6158

Closed

Scottmitch approved these changes Dec 28, 2016

View reviewed changes

Scottmitch requested changes Dec 28, 2016

View reviewed changes

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from f6e46c8 to 6821fe5 Compare February 8, 2017 22:44

rkapsi changed the base branch from 1.1.33 to master February 8, 2017 22:45

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 6821fe5 to 22fc317 Compare February 8, 2017 22:48

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 22fc317 to 242c40d Compare February 9, 2017 13:17

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 242c40d to 61a44c9 Compare February 23, 2017 18:39

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 61a44c9 to 7be704f Compare February 24, 2017 13:58

Scottmitch requested changes Mar 2, 2017

View reviewed changes

Scottmitch self-assigned this Mar 2, 2017

Scottmitch added the feature label Mar 2, 2017

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch 3 times, most recently from d1188b7 to 5886b84 Compare March 6, 2017 14:29

Scottmitch requested changes Mar 6, 2017

View reviewed changes

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 77cffe9 to d67b985 Compare March 9, 2017 14:37

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from fa14107 to 3420550 Compare March 9, 2017 16:57

rkapsi commented Mar 9, 2017

View reviewed changes

Scottmitch reviewed Mar 9, 2017

View reviewed changes

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 14dcf65 to 5e055e5 Compare March 13, 2017 14:24

rkapsi force-pushed the rkapsi/netty-ocsp-stapling-2 branch from 5e055e5 to 7c3cab6 Compare March 16, 2017 17:19

Scottmitch approved these changes Mar 28, 2017

View reviewed changes

Scottmitch closed this Mar 28, 2017

ghost mentioned this pull request Apr 18, 2017

OCSP Stapling (for improving HTTPS effective throughput and allow scalability) eclipse-vertx/vert.x#1689

Open

rkapsi deleted the rkapsi/netty-ocsp-stapling-2 branch August 24, 2018 15:53


		if (client) {
		error = SSL_CTX_set_tlsext_status_cb(c->ctx, netty_ocsp_client_callback);


		#if !defined(TCN_NO_OCSP) && !defined(OPENSSL_IS_BORINGSSL)

		#ifndef TCN_CLIENT_CALLBACK_ERROR

Uh oh!

Conversation

rkapsi commented Dec 27, 2016

Uh oh!

rkapsi commented Dec 27, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Scottmitch left a comment

Choose a reason for hiding this comment

Uh oh!

rkapsi commented Feb 8, 2017

Uh oh!

rkapsi commented Feb 23, 2017

Uh oh!

Scottmitch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Scottmitch Mar 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Scottmitch Mar 2, 2017 •

edited

Loading

Scottmitch commented Mar 2, 2017 •

edited

Loading