Re: Issue 132896 in chromium: TLS/SSL support in the socket API

[chro...@googlecode.com]

Updates:
Labels: Action-DesignDocNeeded

Comment #2 on issue 132896 by rsl...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

From the net/ stack, I've been pushing back on this because of the use
cases involving:
- How to handle errors (particularly, certificate errors):
- Can the application/extension indicate they're acceptable? What risks
does this pose to users/user information?
- If not, is there a way for the user to accept the error? Right now, we
only show interstitials on main frame navigations, which don't help
apps/extensions.
- How does certificate verification happen?
- Does it happen exclusively with the system APIs?
- Can applications supply their own trust anchors? Are they mutually
exclusive or additive with the system APIs?
- What about applications that want to verify that custom (eg:
enterprise-specific) EKUs/policy OIDs are present in the chain?
- How does client auth happen?

While there are abstractions, much of the code is designed within the model
of web browsing, but increasing Apps (whether this is Apps V2, Extensions,
NaCl, Pepper, or even Pepper Flash) have different needs or requirements.

SSH support is very much a different thing entirely than SSL, and there is
no such support in net/, nor in Chrome itself. I'd give a little push back
on 'bloatiness' grounds, since it's something that demonstrably can be
wholly implemented externally (eg: SSH-in-a-tab), so I'm not sure 'native'
support is needed.

[chro...@googlecode.com]

Updates:
Labels: Hotlist-AppsKnownIssues

Comment #3 on issue 132896 by dim...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Status: Started
Cc: za...@google.com

Comment #4 on issue 132896 by mih...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Luke has a CL out: https://chromiumcodereview.appspot.com/10580028/

[chro...@googlecode.com]

Comment #8 on issue 132896 by re...@reimuhakurei.net: TLS/SSL support in

the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

I am currently working on an IRC client for Chrome, and this is an
absolutely required feature in order for it to be useful at all, really.
For this use-case scenario, SSL support in the sockets would need to allow
the app to ignore any certificate errors, because almost every IRC server
out there uses either self-signed or invalid certificates for SSL. Maybe
have an "ignore-certificates" option or something, for if the app is
expecting an invalid SSL cert anyway?

[chro...@googlecode.com]

Comment #9 on issue 132896 by rsl...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

If the app is ignoring self-signed or invalid certificates, there is
absolutely zero security benefit against an active attacker, and it is
generally trivial to become an active attacker.

See http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf for
excellent research that shows how common it is to misuse such APIs and
eliminate any security benefits.

[chro...@googlecode.com]

Comment #10 on issue 132896 by re...@reimuhakurei.net: TLS/SSL support in

the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Yes, but IRC servers typically have invalid SSL certificates anyway; the
only points of SSL for IRC are:
a) Preventing casual eavesdropping (guy sitting there on a laptop with
Wireshark)
b) Bypassing firewalls

Encrypting things in a way that is trivial to crack is still better than
not encrypting them at all.

[chro...@googlecode.com]

Comment #11 on issue 132896 by rsl...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Please see the referenced article and the related literature. SSL in
promiscuous mode does little to prevent a) in practice. There is a real and
present danger to using SSL, in promiscuous mode, for b), in that it
implies a level of security and encryption that is simply not present. The
danger between developers' expectations of security, users' expectations of
security, and site operators' expectations of security are enough to mean
that allowing such invalid certificates is not a significant win for users
or security.

Given that site operators can trivially obtain cheap-to-free certificates
(such as, eg, from startSSL), there is little compelling reason to continue
with invalid certificates.

I'm appreciative of the use cases for SSL, and even potentially for custom
trust anchors (although there is an entirely separate issue of secure
in-band delivery of those trust anchors), but I'm not much more hesitant
towards the bypassing of errors.

[chro...@googlecode.com]

Comment #13 on issue 132896 by re...@reimuhakurei.net: TLS/SSL support in

the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

After skimming through the PDF you linked, I can see what kinds of problems
adding something like this would cause. App developers would likely use bad
SSL certificates or just ignore them even when there is no valid need to.
Therefore, I propose the following solution:

1: User installs the application AwesomeSampleApp
2: AwesomeSampleApp connects to a server, whose configuration is entirely
out of its developer's control, which has an invalid SSL certificate.
3: Chrome notices that the certificate is invalid, pauses
AwesomeSampleApp's code, and blacks out AwesomeSampleApp's window in a way
similar to UAC on Windows, except maybe a red color instead of grey. Above
the blacked-out window, Chrome pops up a dialog that looks just like the
standard SSL certificate warning you would get during normal web browsing,
but with a check-box for "remember this choice"
4: a) If the user chooses to not accept the certificate, Chrome returns an
error message to the app, and the app resumes normal operation.
b) If the user chooses to accept the certificate, Chrome allows the app
to continue connecting, and resume normal operation.

For added security, this behavior could be disabled by default, and require
a setting in the manifest.json file, or a parameter to the connect function.

[chro...@googlecode.com]

Comment #14 on issue 132896 by macge...@gmail.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Actually, Chrome does seem to remember invalid SSL certificate choices (I
only use Chrome on ChromeOS), so the dialog could just be a modal version
of the usual invalid certificate warning.

[chro...@googlecode.com]

Comment #15 on issue 132896 by re...@reimuhakurei.net: TLS/SSL support in

[chro...@googlecode.com]

Comment #16 on issue 132896 by sugar...@google.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

I'm working on an IRC client as well, for which SSL is extremely important.
I see that this task is marked as started but has no owner. Is there still
progress being made towards completing this?

[chro...@googlecode.com]

Comment #20 on issue 132896 by sandberg...@gmail.com: TLS/SSL support in

the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Is there any progress on this?

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #21 on issue 132896 by pulp...@gmail.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

As a stepping stone, the socket API could require a hash of the server's
TLS/DTLS certificate and fail if the certificate does not match. This moves
certificate validation to the developer, insulating the user from any
decision. This style of client-side certificate pinning is, incidentally,
one solution to the issues in the cited Android paper.

[chro...@googlecode.com]

Comment #24 on issue 132896 by paulncox: TLS/SSL support in the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

There are plenty of good use cases to illustrate why this is important - Im
writing a simple email sender and I need TLS support to access many
servers, increasingly APIs use secure connections etc
So I guess my question is why cant the socket connection simply fail with
an error code for invalid cert etc and let the app writer deal with it?

[chro...@googlecode.com]

Comment #27 on issue 132896 by g...@gull.us: TLS/SSL support in the socket
API
http://code.google.com/p/chromium/issues/detail?id=132896

I'm curious if anyone knows of a Javascript implementation of TLS, as that
would solve the problem. I'd be tempted to write one, but I don't trust
myself to implement crypto -- I know just enough to know that I don't know
NEARLY enough, if you know what I mean.

[chro...@googlecode.com]

Comment #28 on issue 132896 by jgl...@cloudbees.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

https://github.com/digitalbazaar/forge

[chro...@googlecode.com]

Comment #29 on issue 132896 by johnwchadwick: TLS/SSL support in the socket
API
http://code.google.com/p/chromium/issues/detail?id=132896

Forge is probably enough, but for the sake of argument, if you want
high-performance, you could also compile a TLS implementation for NaCl.

[chro...@googlecode.com]

Comment #30 on issue 132896 by g...@gull.us: TLS/SSL support in the socket
API
http://code.google.com/p/chromium/issues/detail?id=132896

Excellent, thanks for the pointer. I'd been searching for such a thing but
hadn't found it. This should be sufficient for my MUSH client app, since
it's pretty low-bandwidth.

[chro...@googlecode.com]

Comment #31 on issue 132896 by sup...@toremote.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Please allow creating a SSL socket over an existing connected plain socket
in implementation, like this:

http://docs.oracle.com/javase/6/docs/api/javax/net/ssl/SSLSocketFactory.html#createSocket(java.net.Socket,
java.lang.String,
int, boolean)

[chro...@googlecode.com]

Comment #32 on issue 132896 by greg.l...@gmail.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Already implemented - see here:
http://api.dartlang.org/docs/releases/latest/dart_io/SecureSocket.html#secure

[chro...@googlecode.com]

Comment #33 on issue 132896 by sup...@toremote.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Thanks, that's great. With this SSLSocket, we basically can do any network
work, can not wait to see it coming to Chrome.

[chro...@googlecode.com]

Comment #34 on issue 132896 by willscott: TLS/SSL support in the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

It looks like chrome's solution to this feature request will likely be to
point us towards the webcrypto API, which will provide encryption routines
enabling SSL/TLS. That support is actively being added, and can be tracked
at:

https://code.google.com/p/chromium/issues/detail?id=245025

[chro...@googlecode.com]

Comment #37 on issue 132896 by tankred....@whiteout.io: TLS/SSL support in

the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Will it be possible to do certificate pinning in chrome packaged apps, by
deploying a certificate in the packaged app?

http://security.stackexchange.com/questions/29988/what-is-certificate-pinning

[chro...@googlecode.com]

Comment #38 on issue 132896 by rsl...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

That's not (yet) on the roadmap, but is a feature that has been discussed.

See Needs-DesignDoc :)

[chro...@googlecode.com]

Comment #41 on issue 132896 by jarro...@gmail.com: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

I'm building an app that require ssl connection via sockets API. Today I've
stopped on this issue. For my app (Advanced Rest Client) it make no sense
to use socket API if I can't send requests to secure servers. You can see
my implementation here:
https://github.com/jarrodek/advanced-rest-client/blob/5e94e9e9ca1b65f5be6e186fc1b1ea0dc8fb82cf/public_html/libs/HttpRequest/ChromeSocketAngular.js

I'm wondering if you can tell me if and when we can expect ssl support in
sockets API?

[chro...@googlecode.com]

Comment #42 on issue 132896 by martinch...@gmail.com: TLS/SSL support in

the socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Read ^^

The developer, lally, writing this feature is sick and in the hospital.
Please let him heal and try not to kill him!

[chro...@googlecode.com]

Comment #45 on issue 132896 by tank...@whiteout.io: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

I wasn't saying that it's not possible. Our shim of the W3C TCPSocket Api
uses forge for chrome.socket and does verification using pinned certs.

https://github.com/whiteout-io/tcp-socket

The problem is that this doesn't scale. We write an email client that
connects via IMAP /SMTP to mail providers. Sure we can pin certs for major
mail providers like gmail, yahoo and outlook.com, but what if a user wants
to configure the app to connect to a custom mail server... am I supposed to
ask the user to upload the server cert? That's horrible UX.

Like Ryan Sleevi said, there is much value from using the browser's own
native and well tested TLS stack (besides having access to installed CA
certs).

[chro...@googlecode.com]

Comment #46 on issue 132896 by bugdro...@chromium.org: TLS/SSL support in
the socket API
http://code.google.com/p/chromium/issues/detail?id=132896#c46

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/5099edfeb7be039ec471b57442ac673c4bc3b0e6

commit 5099edfeb7be039ec471b57442ac673c4bc3b0e6
Author: la...@chromium.org
<la...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Sat Jul 26 20:16:17 2014

An implementation of chrome.socket.secure().

It adds a new TLSSocket type in the extensions:: namespace, that acts
similarly
to TCP/UDPSocket. Failures to enable TLS will auto-close the socket.

API Proposal:
https://docs.google.com/a/google.com/document/d/1XSjBtLjyGXQmgB0XE4kxuvM0p2yKI_8T5aOiKDJ9lFg/edit

BUG=132896
TESTED=some, mostly with a custom chrome app, and with the included test.

Review URL: https://codereview.chromium.org/76403004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@285804
0039d316-1c4b-4281-b951-d872f2087c98

[chro...@googlecode.com]

Comment #47 on issue 132896 by bugdro...@chromium.org: TLS/SSL support in
the socket API
http://code.google.com/p/chromium/issues/detail?id=132896#c47

------------------------------------------------------------------
r285804 | la...@chromium.org | 2014-07-26T20:16:17.821251Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/sockets_tcp/sockets_tcp_api.h?r1=285804&r2=285803&pathrev=285804
A
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/tls_socket.cc?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests_unit.gypi?r1=285804&r2=285803&pathrev=285804
A
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/tls_socket.h?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/api/sockets_tcp/sockets_tcp_apitest.cc?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/common/api/sockets_tcp.idl?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/socket_api.cc?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/socket_api.h?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/api_resource_manager.h?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/extensions.gyp?r1=285804&r2=285803&pathrev=285804
A
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/api/socket/tls_socket_unittest.cc?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/common/api/socket.idl?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/sockets_tcp/api/background.js?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/socket.h?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/extension_function_histogram_value.h?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/tools/metrics/histograms/histograms.xml?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/tcp_socket.cc?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/socket/tcp_socket.h?r1=285804&r2=285803&pathrev=285804
M
http://src.chromium.org/viewvc/chrome/trunk/src/extensions/browser/api/sockets_tcp/sockets_tcp_api.cc?r1=285804&r2=285803&pathrev=285804

An implementation of chrome.socket.secure().

It adds a new TLSSocket type in the extensions:: namespace, that acts
similarly
to TCP/UDPSocket. Failures to enable TLS will auto-close the socket.

API Proposal:
https://docs.google.com/a/google.com/document/d/1XSjBtLjyGXQmgB0XE4kxuvM0p2yKI_8T5aOiKDJ9lFg/edit

BUG=132896
TESTED=some, mostly with a custom chrome app, and with the included test.

Review URL: https://codereview.chromium.org/76403004

-----------------------------------------------------------------

[chro...@googlecode.com]

Updates:
Status: Fixed
Owner: la...@chromium.org

Comment #48 on issue 132896 by la...@chromium.org: TLS/SSL support in the
socket API
http://code.google.com/p/chromium/issues/detail?id=132896

Using the built-in TLS stack. Sorry, no ability to add/manage certs here,
just use the existing configuration.