I'm doing some performance analysis on an SSL-encrypted connection and I want to tease apart how much time is saved by not MACing (I still want AES-CBC however). Is there a way to disable just HMAC via the API?
You can't disable it in SSL or TLS, period, regardless of the implementation. It is a required part of the protocol. Without it the protocol wouldn't be secure.
I did a performance study a few years ago that showed that over the Internet, SSL is only 3x as slow as plaintext. I was pleasantly surprised at that.
If you want faster SSL, invest in a hardware crypto accelerator.
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).
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.
I have a low volume (<500 PDFs/year) application for automated digital-signing of PDF files using iText in Java on Linux.
I've got iText adding a digital signature to PDFs using my SSL certificate. Is this a valid method to prove the PDF was generated by my domain (e.g. server)? Can it be used somehow to get the green checkmarks showing "trust" in Adobe Reader?
If not, I should use a certificate intended for PDFs (e.g. not my SSL certificate), so that the little green checkmarks indicating "trust" appear naturally when the user opens the PDF document.
The book http://itextpdf.com/book/digitalsignatures does a great job introducing this topic to me (I have very little experience in this area).
The book talks about a SafeNet Luna device (an HSM), but's it is much too expensive. I only require a minimal solution, and the Luna has a lot of bells and whistles. The Luna PCIe device is less expensive, but I don't require any features other than providing a certificate I can use to sign. Also, the USB-based SafeNet iKey device seems only to be marketed to Windows devices. Has anyone got iKey working with Linux? Is it even possible? Do other companies offer USB based devices that work on Linux?
I'm looking for a minimal solution for serving automated digitally signed PDFs on a Linux box. I'm sure a lot of small businesses have similar needs. I'm just trying to tap into existing knowledge out there. How do people solve this problem?
The solutions I see for automating this process assume large corporations using Adobe Live Cycle, and priced accordingly (see for example: https://www.globalsign.com/pdf-signing/compare-pdf-signing.html). But small businesses need to automate things too.
Ideally someone would sell a certificate similar to the SSL certificates, but for PDF files. Is there such a thing?
Is hardware (of some sort) a requirement (seems so)? If hardware is a requirement, are there any minimal solutions out there (e.g. with limited functionality other than enabling digital signing)?
Hoping someone can help me see the forest from the trees. What's the conventional wisdom?
Regarding signing with your SSL certificate: in a future iText version, we make require that the key-usage of the certificate indicates that the certificate can be used for non-repudiation. For now, we make checking the key-usage the responsibility for the developer, but in a perfect world, you should only sign with certificates suited for non-repudiation, and your SSL certificate probably doesn't allow this.
Regarding the green check mark: unless you can ask the consumers of your PDFs to add the root certificate of your certificate to the list of trusted identities, you'll always need a public/private key stored on hardware to get a green check mark.
Regarding the price of an HSM / USB key. USB keys are much cheaper, but usually they are meant for manual use (usually they have a limit of signing only once every second). I think that GlobalSign has a flavor of keys that work on Linux. As for HSMs, one of our customers told us that he bought one from Utimaco because it was less expensive (but I don't know what budget he had or spent).
No price info, but maybe a good read for inspiration: http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf
I've spent hours now looking for an answer to this question and I can't seem to find it anywhere.
Are there any tutorials or sample code that help with setting up an http connection so that a user can use the browser to save the application coredata sqlite file to the desktop and/or send a previous sqlite backup to the app?
Thanks in advance.
You can use the Cocoa HTTP Server. I have used it before, and it works great.
It has:
Built in support for bonjour broadcasting IPv4 and IPv6 support
Asynchronous networking using GCD and standard sockets
Password protection support
SSL/TLS encryption support
Extremely FAST and memory efficient
Extremely scalable (built entirely upon GCD)
Heavily commented code
Very easily extensible WebDAV is supported too!
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