which browser is using openssl - ssl

It is said that openssl are widely used, however, as far as I know, the most popular browsers seem not use openssl, instead, they use other SSL libraries like:
NSS (for all firefox and chrome in Linux)
SChannel (for browsers in Windows)
Secure Transport (for browsers in Mac OS X).
Am I right? Or is there any concept I'm taking wrong?
Thanks.

OpenSSL is widely used in web server, according to netcraft survey (http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html) it can be over 60% of all web servers : Apache with mod_ssl, Google and Nginx. For browser it is just not widely used.

Related

Apache Openssl Compression

I am using openssl 1.0.1 on os x el capitan. I want to enable TLS compression. I have set SSLCompression on but still doesn't do compression.
P.S. I know that compression is unsafe but I have to enable it to demonstrate CRIME attack for my class. I have also got browser that supports compression, so browser doesn't seem to be issue. The ServerHello message always decide to use null(0) compression.
Then the issue seems to be located serverside.
If you are the administrator of the server and if the server runs a recent OS, I'm afraid you'll probably have to manually compile OpenSSL with option zlib on it.

Expected Compatibility Issues with upcoming TLS/SSL Cipher Suite update on Azure WebApps?

A little while ago we received an email from the Azure Team regarding an upcoming TLS/SSL cipher suit update, kicking in after July 18th with the following instruction:
You can check whether the clients that access your web apps will still function correctly by testing them against https://testsslclient.trafficmanager.net/. Your client is compatible if you receive a 200 HTTP status—the page will display a “SSL client test complete!” message.
After testing our standard clients it looks like IE7 and IE8 fail the test on XP SP3 (Chrome still works).
Does anybody else have results of what clients are expected to fail? (It would have been nice if the Azure Team would have provided a list of expected incompatibilities).
Also: the test page uses an SHA2 certificate. We are still using SHA1 on some sites, due to be updated eventually. Does anybody know if the update will have any impact on SHA1 certificates?
Related link
Yes, XPSP3 IE 7/8 will fail because they don't support any of the ciphers that will be on the updated list. I don't think we have a list of clients that will / will not work, because the list is quite large ... you have to worry about embedded devices like PoS terminals etc, and not just browsers.
SHA-1 certificates will still be supported in Azure WebApps, although some browsers like Chrome will complain about obsolete cryptography etc.
We have repeated our tests today and IE7 and IE8 on XPSP3 now pass the client test at https://testsslclient.trafficmanager.net.
We assume the implementation of the TLS/SSL cipher suit has been updated to allow for this now...

Disable SNI in a modern browser

Is there a way to temporarily disable SNI in a modern browser?
E.g. to test a website availability for older clients. (Should one worry about them since POODLE?)
Probably the best way to test availability for older clients is to actually try out older clients. Microsoft provides VM images for browser compatibility testing at https://www.modern.ie/, which probably covers most of the desktop-based legacy clients, at least.
Another great resource for testing web site SSL/TLS compatibility in general is the Qualys SSL Server Test, which tries all the protocols and gives a simulation of what cipher suites browsers will be negotiating, as well as other useful information.
I'm not aware of any specific modern browser setting for disabling SNI specifically. Probably it'd open up a whole bunch of code paths that would need testing for not really any benefit, and support for it is probably deep within whatever library the browser is using for SSL/TLS support.

Remotely hosted HTTPS Images not displaying in Safari 4.1.3 on Macs

Working with a ticketing system site that must be accessed via HTTPS at https://www.threestages.net
Our images are hosted elsewhere ( https://wserver.flc.losrios.edu/~vapa/) and also accessed via HTTPS.
We have multiple reports that Safari 4.1.3 on Macs is not displaying the images. We have no reports of this behavior from any other browser or platform.
Any one have any notion what that would be about?
Thanks for any thoughts,
JG
So it turns out that Safari has an issue with the SSL Cert at https://wserver.flc.losrios.edu/
http://www.sslshopper.com/ssl-checker.html let me know that
The certificate is not trusted in all
web browsers. You may need to install
an Intermediate/chain certificate to
link it to a trusted root certificate.
Thanks for looking at this. Valuable lessons learned:
Even if 4 out of 5 browsers accept an SSL Cert that doesn't mean they all do
Just because the sysadmin says it's not his problem/mistake doesn't make it so!
Check everything. Then repeat.

is godaddy SSL standard certificate compatible with *all* browsers?

Could you answer to at least one of these questions:
1) Is godaddy SSL standard certificate compatible with all browsers (chrome and safari on iphone, or android browsers included) ?
http://www.godaddy.com/ssl/ssl-certificates.aspx?ci=8979
2) Is it running on Apache servers ?
Those particular certs claim to have 99% Browser Recognition.
I think that's pretty high but I have found the Godaddy certs to be pretty good.
Remember they are probably not including mobile browsers in this statistic.
Also have you checked out this page as they are cheaper?
http://www.godaddy.com/ssl/ssl-certificates-verisign.aspx?isc=sslqgica15