Fixed
Status Update
Comments
bd...@google.com <bd...@google.com> #2
The main problem with supporting SNI in the browser is that many sites choke on TLS extensions, especially lesser known ones. Chrome and other browsers try to retry the connection without TLS (and without compression, which technically is SSL and not TLS)
We have moved forward with this in 2.3 (Gingerbread) and javax.net.ssl.HttpsURLConnection does attempt to handshake with SNI (and automatically falls back to SSL w/o compression if there are problems). Unfortunately the browser uses Apache HTTP Client and there was not a simple local fix to make it retry failed connections, so it is overly conservative and does not include SNI information.
I'm reassigning to someone from the browser team for tracking but this is definitely a known issue.
We have moved forward with this in 2.3 (Gingerbread) and javax.net.ssl.HttpsURLConnection does attempt to handshake with SNI (and automatically falls back to SSL w/o compression if there are problems). Unfortunately the browser uses Apache HTTP Client and there was not a simple local fix to make it retry failed connections, so it is overly conservative and does not include SNI information.
I'm reassigning to someone from the browser team for tracking but this is definitely a known issue.
vi...@gmail.com <vi...@gmail.com> #3
Thanks for the fast comment, i guessed that this was a known issue but while testing a website using SNI for access from android i saw the failure and didn't find any issue in the public tracker related to it so i created it.
Now i'll also be able to update the wikipedia article (http://en.wikipedia.org/wiki/Server_Name_Indication ) with more informations and as opera mobile on android support SNI i'll be able to redirect my users to this browser for the time being.
Now i'll also be able to update the wikipedia article (
bd...@google.com <bd...@google.com> #4
Yes, Opera works because it actually makes all its connections to sites through their own servers, not from the device directly. The downside is that it won't work with intranet sites since they aren't accessible from Opera's servers.
I tried the Firebox beta and SNI worked fine with it as well thehttps://alice.sni.velox.ch/ test site.
(to be clear also, this was a known issue internally, you didn't miss anything in the public issues that I'm aware of)
I tried the Firebox beta and SNI worked fine with it as well the
(to be clear also, this was a known issue internally, you didn't miss anything in the public issues that I'm aware of)
se...@gmail.com <se...@gmail.com> #5
iOS 4+ supports SNI and once Android supports it, it bridges the gap. I hate to see android listed with windows XP for not supporting SNI. I hope android eventually going to support it but considering how frequently OEM upgrading their android devices it would be necessary to support as early as possible.
Thanks,
Senthilkumar Peelikkampatti
Thanks,
Senthilkumar Peelikkampatti
jh...@googlemail.com <jh...@googlemail.com> #6
Seeing that all other modern platforms do not have a problem with SNI support, I would strongly urge the developers to rethink their position. SNI and the needed changes to OpenSSL are long upstream and Simply Work. IMHO supporting TLS connections by default should be a no-brainer in times of Phishing and MITM attacks. Please fix.
jh...@googlemail.com <jh...@googlemail.com> #7
Seeing that all other modern platforms do not have a problem with SNI support, I would strongly urge the developers to rethink their position. SNI and the needed changes to OpenSSL are long upstream and Simply Work. IMHO supporting TLS connections by default should be a no-brainer in times of Phishing and MITM attacks. Please fix.
vi...@gmail.com <vi...@gmail.com> #8
BTW Opera Mobile isn't using any proxy and does a direct connection (as well as rendering) from the mobile. The version of opera doing server side rendering is the Mini version.
The current state in android is currently :
* Default browser: No support
* Opera Mini : OK but no access to intranet
* Opera Micro : OK but in beta
* Firefox : OK but in beta and unusable with current partition
sizes on most android phones as it create a multi megabyte cache
on main partition.
* Java applications, Ok since Gingerbread. Obviously you need a rendering
engine to render webpages but at least REST calls could now work.
Basically there are downsides to every solution but the clear picture is that SNI support is now working everywhere in android except in the default browser.
Next version of Debian (Stable !!!) will even integrate the correct version of apache to support SNI server side out of the box...
The current state in android is currently :
* Default browser: No support
* Opera Mini : OK but no access to intranet
* Opera Micro : OK but in beta
* Firefox : OK but in beta and unusable with current partition
sizes on most android phones as it create a multi megabyte cache
on main partition.
* Java applications, Ok since Gingerbread. Obviously you need a rendering
engine to render webpages but at least REST calls could now work.
Basically there are downsides to every solution but the clear picture is that SNI support is now working everywhere in android except in the default browser.
Next version of Debian (Stable !!!) will even integrate the correct version of apache to support SNI server side out of the box...
jh...@googlemail.com <jh...@googlemail.com> #9
IMHO SNI is a MUST, not an option. You cannot promote the use of https everyhwere and then stop at the browser. Same wrt client certificate support that is also in a sorry state in Android. IMHO Android is lagging behind years wrt to support of more privacy and secuirity for the average user. Please fix.
jh...@googlemail.com <jh...@googlemail.com> #10
[Comment deleted]
bd...@google.com <bd...@google.com>
sc...@gmail.com <sc...@gmail.com> #11
SNI is definitely a must. Using named virtual hosts is becoming more and more common and popular (who the hell wants to pay for more IP addresses just because you need another site secured?). Please fix this - make it a priority.
at...@gmail.com <at...@gmail.com> #12
Hi! I have noticed that the status of this has changed to 'released'. In what ersion has is been released? Will it be included in my new Android handset's update (currently on 2.3.3, waiting eagerly for 2.3.4).
bd...@google.com <bd...@google.com> #13
atur...@googlemail.com, it is marked Target-Honeycomb, so 3.0.
SNI might work on 2.3 with alternative browsers that have their own https stack, such as Firefox. Usually I test withhttps://gmail.com
(changing owner since the old username was no longer valid)
SNI might work on 2.3 with alternative browsers that have their own https stack, such as Firefox. Usually I test with
(changing owner since the old username was no longer valid)
ma...@klauseder.com <ma...@klauseder.com> #14
Very disappointing that this still hasn't been implemented. Using 2.3.5 on a Galaxy S2, doesn't work in included browser nor in dolphin browser. :/
ch...@gmail.com <ch...@gmail.com> #15
SNI is also not working in Android 2.3.3 on Droid 2. Perhaps the status or the Target should be updated.
bd...@google.com <bd...@google.com> #16
chrishie...@gmail.com, the status is that the issue has been addressed in Honeycomb. There are no plans to address it in earlier releases.
vi...@gmail.com <vi...@gmail.com> #17
chrishie...@gmail.com :
Non "corporate gibberish" summary :
* Gingerbread (2.3) Will never get this update officially.
* Honeycomb (3.0) contains the fix but isn't available on phones.
* Ice Cream Sandwich (4.0) will provide this feature to phones but isn't already available (soon).
Also :
* The fix from Honeycomb could have been backported by the manufacturers that got it's source code but none that I know off did it.
* As Honeycomb is a closed source release none of the alternative distribution could merge the patch without re-developing it.
* As Ice Cream Sandwitch will include this patch it will be in all distributions and could even be backported to Gingerbread.
Sadly coupled with the fact that google don't control at all the updates of previous phones it lock SNI in an "Unusable for most of Android users" state for 2+ Years at least for environements where you don't control users hardware.
At least now for companies you could plan an upgrade (software or hardware depending on the phone models your employees got) as soon as ICS is released.
Non "corporate gibberish" summary :
* Gingerbread (2.3) Will never get this update officially.
* Honeycomb (3.0) contains the fix but isn't available on phones.
* Ice Cream Sandwich (4.0) will provide this feature to phones but isn't already available (soon).
Also :
* The fix from Honeycomb could have been backported by the manufacturers that got it's source code but none that I know off did it.
* As Honeycomb is a closed source release none of the alternative distribution could merge the patch without re-developing it.
* As Ice Cream Sandwitch will include this patch it will be in all distributions and could even be backported to Gingerbread.
Sadly coupled with the fact that google don't control at all the updates of previous phones it lock SNI in an "Unusable for most of Android users" state for 2+ Years at least for environements where you don't control users hardware.
At least now for companies you could plan an upgrade (software or hardware depending on the phone models your employees got) as soon as ICS is released.
[Deleted User] <[Deleted User]> #18
If servers choke on TLS extensions, just get the user an error message stating that it's the servers fault, and also remove the fallback from chrome. At some time, server owners will be forced to support state of the art technology like they should.
[Deleted User] <[Deleted User]> #19
[Comment deleted]
[Deleted User] <[Deleted User]> #20
Hello All,
I am developer and I am facing the same issue. Do you know how we can overcome this issue from server side.
I am developer and I am facing the same issue. Do you know how we can overcome this issue from server side.
bd...@google.com <bd...@google.com> #21
sven.k.heinemann, see http://www.imperialviolet.org/2012/04/11/falsestart.html for a discussion of trying to force server owners to upgrade to support state of the art technology like they should.
bd...@google.com <bd...@google.com> #22
dipu, the lack of SNI means https sites can be virtual hosted on the same IP. the workaround is to use different IPs for different https hosts. Note this can still be done on one server, it just needs multiple IP addresses to distinguish which request is for which server.
Description
- Steps to reproduce the problem.
- Open the android browser
- Browse to the page
- What happened.
- The browser displayed a security alert but shouldn't have if SNI was working.
- The test site doesn't report SNI as enabled.
- What you think the correct behavior should be.
- As the chrome browser and all other modern browsers SNI should be supported.
Don't forget to mention which device you have, and which version of Android
is installed on it. (Find it under Home > Menu > Settings > About phone.)
- The device is an HTC Desire
- Android is at version 2.2 (CyanogenMod-6.0.2-Desire) but the android emulator with the 2.2 rom seem to have the same behavior.