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.
Related
I found many useful online tools that provide SSL/TLS analysis. Is there any offline or online tool that would check if specific ciphers are safe?
Sometimes servers are not visible in internet or admin wish not to inform the rest of the world that his server is not safe enough.
I know that I can run nmap against my own server, however quick static analysis would be fine.
For example, Qualys sells this product that you need for internal scanning. If you're not going to buy anything, you can script around openssl (it wouldn't take long).
I would like to implement a video / audio call feature from a browser. The goal is to allow two users to communicate remotely without having to install a third part (when I say third part, I'm talking about a software or an extension on a browser).
I know WebRTC, which is very popular today and free. However, it is very difficult to implement and the documentation is difficult to understand (not very easy for a beginner).
Here is the official webRTC documentation, and honestly, where to start? https://webrtc.org/start/
If you have an experience about WebRTC, is it possible to share with positive or negative points? This would be very useful for the community.
Moreover, if you have experience with another library, I think it would be interesting to hear it.
There is no other way to develop a call service in a website without the use of WebRTC today.
The alternatives are:
Use WebRTC
Use Flash (which is... dead)
Use a plugin (which is... dying as a mechanism in browsers)
Use an app you download (not exactly a service in a website)
Node.js is the way to go, but you will need to learn some new technology, especially when it comes to the backend.
The servers you will need are:
1. The traditional web application server
2. A signaling server (the one you plan on using Node.js for - you can use that for the web application server as well)
3. A STUN/TURN server (for NAT traversal)
4. Maybe a media server, depending on your use case
For some alternative open source and commercial products, you can check this WebRTC Developer Tools Landscape
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...
Is it possible to check via web site if end use has installed .NET Framework4 Client ?
It's desirable if this way doesn't use any plugins (flash or silverlight).
From the server side, the best you can do is sniff the user agent that is sent with the request to the website. In it you'll usually see something along the lines of:
.NET <version number>
Or something to that effect.
Of course, there are major drawbacks to this (as there is with any user agent detection) which warrant not doing this:
The user agent can be spoofed
Parsing strings that are not structured is generally error-prone
Not all browsers (i.e. non-IE browsers) are obligated to send this information
That said, ChrisF's comment asking why is somewhat relevant, in the sense that you are better off having code execute on the client side to detect this, as there are more definitive ways (checking the registry) of determining if .NET 4.0 is installed on the client, using mechanisms that you just don't have available to you from the server side.
The thing is, if the code is served up from the server side, then it will probably be sandboxed in some way, and you'll have to figure out a way to access the registry (which is typically restricted in most sandboxes for code downloaded from the web).
I am working with an electronics appliance manufacturer to embed LAN based control systems into the products. The idea is to serve up a system configuration/control interface through a web browser so clients never need to install software. We can communicate with the appliance by sending and receiving serial data through the embedded module. Since the appliance can also be controlled from a front panel UI, it creates a challenge to keep a remote web interface in sync with very low latency. It seems like websockets or some sort of Push is what we need for handling real time events from the server to clients.
I am using a Lantronix Mathport AR embedded device server. Out of the box the unit will serve up any custom HTML and java servlets/applets. We have the option to install a lightweight Linux distro if we need more flexibility. I am not sure how to implement any server side apps since the device is not running standard Apache. I believe it is using Boa.
Can anyone guide me in the right direction of how to do this?
Some general info...The WebSocket protocol (draft spec here) is a simple layer on top of TCP. What this means is that, if you already have a TCP server for your platform, implementing the WebSocket is just a matter of hours. The protocol specifies a handshake and two ways of sending data frames.
I strongly suggest you start by reading the 39 pages spec.
As Tihauan already mentioned, start by reading the spec, and also note that there are still some changes ongoing, although websockets is now more stable than it was 1 year ago.
Key point for me was the requirement that websocket data is entirely UTF-8 text, which lends itself nicely to JSON based message definitions.
Our system uses a form of embedded linux, so we then added and made use of the following libraries:
"libwebsockets" from:
http://git.warmcat.com/cgi-bin/cgit/libwebsockets/
"jansson" from:
http://www.digip.org/jansson/
Using the above as support libraries, we created an internal lightweight "client/server" that allowed our other software modules to register for certain, applicable, websocket messages, and respond as needed. Worked great.
Good luck and best regards,
I'm a bit late, but Mozilla posted a guide entitled "Writing WebSocket servers", which literally guides you through writing a websocket server.
You will need to already know how HTTP works and have medium programming experience. Depending on language support, knowledge of TCP sockets may be required. The scope of this guide is to present the minimum knowledge you need to write a WebSocket server.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers