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.

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

OpenSSL error from bufferevent: tlsv1 alert unknown ca #131

Closed
CyberSolid opened this issue Apr 18, 2016 · 9 comments
Closed

OpenSSL error from bufferevent: tlsv1 alert unknown ca #131

CyberSolid opened this issue Apr 18, 2016 · 9 comments

Comments

@CyberSolid
Copy link

CyberSolid commented Apr 18, 2016

I can't seem to get HTTPS for all sources using sslsplit-0.5.0 on Ubuntu 14.04 when trying to see an Android App.

For the empty logs it seems to generate the following message :
Error from bufferevent: 0:- 336151576:1048:tlsv1 alert unknown ca:20:SSL routines:148:SSL3_READ_BYTES

I set up an ethernet bridge between 2 ethernet devices.

I generated the certs using :

openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt

Installed the cert on the android device using : Settings > Security > Install From SD Card ( For VPN & Apps )

Port forwards :

iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 5223 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443

and start sslsplit using :

sudo ./sslsplit -P -D -l connections.log -j /tmp/sslsplit/ -S /tmp/sslsplit/logdir/ -k ca.key -c ca.crt https 0.0.0.0 8443 http 0.0.0.0 8080

Debug :

Working :

SNI peek: [graph.facebook.com] [complete]
Connecting to [179.60.195.7]:443
===> Original server certificate:
Subject DN: /C=US/ST=CA/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.com
Common Names: *.facebook.com/*.facebook.com/*.facebook.net/*.fb.com/*.fbcdn.net/*.fbsbx.com/*.m.facebook.com/*.messenger.com/*.xx.fbcdn.net/*.xy.fbcdn.net/*.xz.fbcdn.net/facebook.com/fb.com/messenger.com
Fingerprint: A0:4E:AF:B3:48:C2:6B:15:A8:C1AA:87:A3:33:CA:A3:CD:EE:C9:C9
Certificate cache: MISS
===> Forged server certificate:
Subject DN: /C=US/ST=CA/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.com
Common Names: *.facebook.com/*.facebook.com/*.facebook.net/*.fb.com/*.fbcdn.net/*.fbsbx.com/*.m.facebook.com/*.messenger.com/*.xx.fbcdn.net/*.xy.fbcdn.net/*.xz.fbcdn.net/facebook.com/fb.com/messenger.com
Fingerprint: 1E:C6:01:71:53:43:D6:1E:FF:D2D5:63:DD:2F:2D:CA:73:85:AD:54
SSL connected to [179.60.195.7]:443 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256
Received privsep req type 01 sz 78 on srvsock 10
Certificate cache: KEEP (SNI match or target mode)
SSL connected from [192.168.1.14]:36833 TLSv1 RC4-MD5
https 192.168.1.14 36833 179.60.195.7 443 graph.facebook.com GET /v2.4/342076679289388?fields=supports_implicit_sdk_logging%2Cgdpv4_nux_content%2Cgdpv4_nux_enabled%2Candroid_dialog_configs%2Candroid_sdk_error_categories&format=json&sdk=android 200 - sni:graph.facebook.com names:*.facebook.com/*.facebook.com/*.facebook.net/*.fb.com/*.fbcdn.net/*.fbsbx.com/*.m.facebook.com/*.messenger.com/*.xx.fbcdn.net/*.xy.fbcdn.net/*.xz.fbcdn.net/facebook.com/fb.com/messenger.com sproto:TLSv1:RC4-MD5 dproto:TLSv1.2:ECDHE-ECDSA-AES128-GCM-SHA256 origcrt:A04EAFB348C26B15A8C1AA87A333CAA3CDEEC9C9 usedcrt:1EC601715343D61EFFD2D563DD2F2DCA7385AD54
SSL disconnected to [179.60.195.7]:443
SSL disconnected from [192.168.1.14]:36833

ERROR :

Connecting to [88.221.254.193]:443
===> Original server certificate:
Subject DN: /C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net
Common Names: a248.e.akamai.net/a248.e.akamai.net/*.akamaihd.net/*.akamaihd-staging.net/*.akamaized.net/*.akamaized-staging.net
Fingerprint: 50:43:3D:50:E2:7D:25:B7:C3:65BA:F5:89:66:35:F0:E7:CA:6D:78
Certificate cache: MISS
===> Forged server certificate:
Subject DN: /C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net`
Common Names: a248.e.akamai.net/a248.e.akamai.net/*.akamaihd.net/*.akamaihd-staging.net/*.akamaized.net/*.akamaized-staging.net
Fingerprint: 45:06:6F:33:25:61:96:1F:69:CBA5:84:89:6B:EA:91:3F:D6:8C:AF
SSL connected to [88.221.254.193]:443 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Received privsep req type 01 sz 80 on srvsock 10
Certificate cache: KEEP (SNI match or target mode)
**Error from bufferevent: 0:- 336151576:1048:tlsv1 alert unknown ca:20:SSL routines:148:SSL3_READ_BYTES**
SSL disconnected to [88.221.254.193]:443
SSL disconnected from [192.168.1.14]:55446

I can see HTTP traffic logs and HTTPS traffic logs, but SOME of the HTTPS logs are empty (0 bytes).

Am I doing something wrong or forgetting a step or is there another fix that I'm missing? Or is there any way I can get around this error?

Also when this happens, the data is not passed through the proxy, and if there is authentication data in the package the app or site will fail.

If anymore info is needed, please inform me.

Thank you in advance

@droe droe changed the title Empty logfiles OpenSSL error from bufferevent: tlsv1 alert unknown ca Apr 19, 2016
@droe
Copy link
Owner

droe commented Apr 19, 2016

For some reason your client is sending a TLSv1 alert "unknown ca" (TLS alert code 48, always fatal) instead of completing the handshake. Why it does this, I don't know. Can you find any information in a client-side debug log? Interesting would be information on the reason for aborting the handshake with TLS alert 48. If this is only traffic from one specific app that connects to specific server infrastructure directly related to the app, it is entirely possible that the app does certificate and/or CA pinning in order to thwart MitM attacks.

droe added a commit that referenced this issue Apr 19, 2016
@droe
Copy link
Owner

droe commented Apr 19, 2016

I committed 1d267e6 to develop in order to indicate which bufferevent (src or dst) is receiving an error. It should show the above error as a src bufferevent error.

@CyberSolid
Copy link
Author

Do you mean client side as in the Android device?
I do have root access to the Android Device, but can't find any logs related to SSL at the moment. Unfortunately I do not have access to the sourcecode of the app so I can't check whether the app does any pinning.

I will compile with the pxyconn.c (1d267e6) from devel to see where the event comes from and get back to you on that.

Thanks a lot for the help and quick response!

@droe
Copy link
Owner

droe commented Apr 19, 2016

Yes, with client-side debug log I mean the application and/or the OS that is initiating the SSL connection that you are intercepting, so either the closed-source App you are reviewing or possibly Android itself.

@CyberSolid
Copy link
Author

CyberSolid commented Apr 20, 2016

just build from dev and I got

Connecting to [88.221.254.193]:443
===> Original server certificate:
Subject DN: /C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net Common Names: a248.e.akamai.net/a248.e.akamai.net/*.akamaihd.net/*.akamaihd-staging.net/*.akamaized.net/*.akamaized-staging.net
Fingerprint: 50:43:3D:50:E2:7D:25:B7:C3:65BA:F5:89:66:35:F0:E7:CA:6D:78
Certificate cache: MISS
===> Forged server certificate:
Subject DN: /C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net
Common Names: a248.e.akamai.net/a248.e.akamai.net/*.akamaihd.net/*.akamaihd-staging.net/*.akamaized.net/*.akamaized-staging.net
Fingerprint: 59:88:20:0D:1E:A6:DD:48:95:D3B0:66:5E:67:CA:6B:65:D9:FC:5F
SSL connected to [88.221.254.193]:443 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Received privsep req type 01 sz 80 on srvsock 10
Certificate cache: KEEP (SNI match or target mode)
Error from src bufferevent: 0:- 336151576:1048:tlsv1 alert unknown ca:20:SSL routines:148:SSL3_READ_BYTES
SSL disconnected to [88.221.254.193]:443
SSL disconnected from [192.168.1.14]:42867
SSL_free() in state 00002180 = SSL_ST_ACCEPT|0180 = 3RCC_A (SSLv3 read client certificate A) [accept socket]
SSL_free() in state 00000003 = 0003 = SSLOK (SSL negotiation finished successfully) [connect socket]
SNI peek: [mzwiso-a.akamaihd.net] [complete]
Attempt reuse dst SSL session

The problem seems to be the Android side.
I checked logs on the android device (using logcat) but couldn't find anything SSL related.

I will look further into the log files but it will take me some time.

Would it possible to have a "resume on error" option that logs the "tlsv1 alert unknown ca" and retries by passing the original cert so the source connection doesn't fail and later data op other sites/ports from apps might be extracted ?

And except looking at log files do you have any other ideas on getting around this?

@droe
Copy link
Owner

droe commented Apr 21, 2016

HSTS can be the reason for a client to reject a connection with that alert message. You can try to flush the HSTS cache and make sure the device is only connecting through sslsplit https/http proxy specs so HSTS is prevented.

The "resume on error" idea is not trivial because the client aborted the connection. We cannot control the client's behaviour after a connection fails. For browsers, an error message would be the norm. We could keep a list of client IPs that sent us an unknown CA alert and prevent them from being intercepted in the future, but this is a very ugly solution both because it requires the management of state and because IP based decision making will cause many connections to be excempted unnecessarily (multiple browsers/apps on same system, multiple clients behind NAT, etc).

I will close the issue since it is not a problem in sslsplit itself. If you find that there is something sslsplit can do to make your client like it's certificate better, please re-open/comment.

@droe
Copy link
Owner

droe commented Apr 21, 2016

Note that your choice of CA certificate related algorithms may be an issue too (use of obsolete algorithms or keysizes).

@CyberSolid
Copy link
Author

Thank you for the clear explanation,
I'll regenerate the certificate with a different keysize to test.

Request : I would like to see the 'Error from src bufferevent: 0:- 336151576:1048:tlsv1 alert unknown ca:20:SSL routines:148:SSL3_READ_BYTES' be logged to the log file instead of the logfile being empty. is this a possibility ?

@droe
Copy link
Owner

droe commented Apr 21, 2016

Makes sense, I moved your suggestion to a separate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants