SignalR alpha for ASP.NET Core 2.0 released

Alpha version of SignalR for ASP.NET Core 2.0 available now
15 September 2017   2013

Alpha version of SiglanR for ASP.NET Core 2.0 released. 

What is SignalR?

ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is "real-time web" functionality? It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.

SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application. While chat is often used as an example, you can do a whole lot more. Any time a user refreshes a web page to see new data, or the page implements Ajax long polling to retrieve new data, is candidate for using SignalR.

What's new?

Let's check main updates.

  • JavaScript/TypeScript Client
    • SignalR for ASP.NET Core has a brand-new JavaScript client. The new client is written in TypeScript and no longer depends on jQuery. The client can also be used from Node.js with a few additional dependencies.
      The client is distributed as an npm module that contains the Node.js version of the client (usable via require), as well as a version for use in the browser which can be included using a <script> tag. TypeScript declarations for the client included in the module make it easy to consume the client from TypeScript applications.
      The JavaScript client runs on the latest Chrome, FireFox, Edge, Safari and Opera browsers as well as Internet Explorer version 11, 10, 9. (Not all transports are compatible with every browser). Internet Explorer 8 and below is not supported.
  • Support for Binary Protocols
    • SignalR for ASP.NET Core offers two built-in hub protocols – a text protocol based on JSON and a binary protocol based on MessagePack. Messages using the MessagePack protocol are typically smaller than messages using the JSON protocol. For example a hub method returning the integer value of 1 will be 43 bytes when using the JSON based protocol while only 16 bytes when using MessagePack. (Note, the difference in size may vary depending on the message type, the contents of the message and the transport used – binary messages sent over Server Sent Events transport will be base64 encoded since Server Sent Events is a text transport.)
  • Support for Custom Protocols
    • The SignalR hub protocol is documented on GitHub and now has extension points that make it possible to plug in custom implementations.
  • Streaming
    • It is now possible to stream data from the server to the client. Unlike a regular Hub method invocation, streaming means the server is able to send results to the client before the invocation completes.
  • Using SignalR with Bare Websockets
    • The process of connecting to SignalR has been simplified to the point where, when using websockets, it is now possible to connect to the server without any client with a single request.
  • Simplified Connection Model
    • In the existing version of SignalR the client would try starting a connection to the server, and if it failed it would try using a different transport. The client would fail starting the connection when it could not connect to the server with any of the available transports. This feature is no longer supported with the new SignalR.
      Another functionality that is no longer supported is automatic reconnects. Previously SignalR would try to reconnect to the server if the connection was dropped. Now, if the client is disconnected the user must explicitly start a new connection if they want to reconnect. Note, that it was required even before – the client would stop its reconnect attempts if it could not reconnect successfully within the reconnect timeout. One more reason to remove automatic reconnects was a very high cost of storing messages sent to clients. The server would by default remember the last 1000 messages sent to a client so that it could replay messages the client missed when it was offline. Since each connection had its own buffer the memory footprint of storing these messages was very high.
  • Sticky Sessions Are Now Required
    • Because of how scale-out worked in the previous versions of SignalR, clients could reconnect and/or send messages to any server in the farm. Due to changes to the scale-out model, as well as not supporting reconnects, this is no longer supported. Now, once the client connects to the server it needs to interact with this server for the duration of the connection.
  • Single Hub per Connection
    • The new version of SignalR does not support having more than one Hub per connection. This results in a simplified client API, and makes it easier to apply Authentication policies and other Middleware to Hub connections. In addition subscribing to hub methods before the connection starts is no longer required.

 

Ledger to Discover HSM Vulnerability

HSM is an external device designed to store public and private keys used to generate digital signatures and to encrypt data, used by banks, exchanges, etc
10 June 2019   1115

A group of researchers from Ledger identified several vulnerabilities in the Hardware Security Module (HSM) devices, which can be used to extract keys or perform a remote attack to replace the firmware of an HSM device. The problem report is currently available only in French, the English-language report is scheduled to be published in August during the Blackhat USA 2019 conference. HSM is a specialized external device designed to store public and private keys used to generate digital signatures and to encrypt data.

HSM allows you to significantly increase protection, as it completely isolates keys from the system and applications, only by providing an API to perform basic cryptographic primitives implemented on the device side. Typically, HSM is used in areas where you need to provide the highest protection, for example, in banks, cryptocurrency exchanges, certification centers for checking and generating certificates and digital signatures.

The proposed attack methods allow an unauthenticated user to gain complete control over the contents of the HSM, including extracting all the cryptographic keys and administrative credentials stored on the device. The problems are caused by a buffer overflow in the internal PKCS # 11 command handler and an error in the implementation of the cryptographic protection of the firmware, which bypasses the firmware check using the PKCS # 1v1.5 digital signature and initiates loading the own firmware in the HSM.

The name of the manufacturer, the HSM devices of which have vulnerabilities, has not yet been disclosed, but it is argued that the problem devices are used by some large banks and cloud service providers. At the same time it is reported that information about the problems was previously sent to the manufacturer and it has already eliminated vulnerabilities in the fresh firmware update. Independent researchers suggest that the problem may be in the devices of the company Gemalto, which in May released an update to Sentinel LDK with the elimination of vulnerabilities, access to information about which is still closed.