I have program which performs successful transfer of data between client(washing machine) and server(HawkBit) by using FreeRTOS+TCP in which we have sockets from FreeRTOS only but now I want to implement TLS over it for which I am using mbedTLS in which we again have function for TCP connections, functions for socket opening closing, every function which we have in FreeRTOS again now I don't know what should I do...!is there any possibility of using the socket from FreeRTOS+TCP and just make CA certification from mbedTLS on the top of it! or I need to implement again everything with mbedTLS what I have implemented before with freeRTOS!
This is using FreeRTOS+TCP through a TLS abstraction https://github.com/aws/amazon-freertos/blob/master/libraries/abstractions/secure_sockets/freertos_plus_tcp/iot_secure_sockets.c - and this is the implementation of the abstraction layer for mbedTLS https://github.com/aws/amazon-freertos/blob/master/libraries/freertos_plus/standard/tls/src/iot_tls.c
Related
I want to use TLS with stm32f4 for the communication safe for the modbus-tcp, but I dont want to use RTOS, how can I do that ? Is that possible? I am using lwip raw api, lwip documentation says it is possible but what is the method ?
In porting mbedtls to an OS without threading context (but with TCP/IP), do you need a thread context (such as blocking I/O - with or without timeout)?
My OS does not provide a thread context. I can create network endpoints, and am notified (via call-back) when data becomes available.
I noticed that the initial SSL negotiation required the ability to read/write SSL records in a synchronous fashion.
I saw that the client programs drove the SSL engine in a loop (WANT_READ/WANT_WRITE). Is this type of polling sufficient to drive the SSL engine?
You don't need threads for mbed TLS. The SSL engine only requires the read/write calls to function (after set-up of the connection of course), but both blocking and non-blocking options are available.
When using OpenSSL in a multithreaded program one needs to implement certain locking callbacks.
When using a singlethreaded program but with nonblocking sockets, do I need to think of this? I mean, is it a prolem if multiple ports are doing SSL_read/write and connect at the same time? COntrast that with a singlethreaded program with blocking swockets where one operation would have to finish beofre the next one.
But with my non blocking app one could try SSL_read and have to call it again and before retrying another connection would also call SSL_read...
It's not a problem to use multiple non-blocking sockets in parallel and do TCP accept, connect and SSL handshake, read, write all at parallel. I'm doing this for years and it is very stable. And since there can be only a single SSL operation at one time you don't need any kind of locking.
I'm going to implement Java VoiP server to work with WebRtc. Implementation of browser p2p connection is really straightforward. Server to client connection is slightly more tricky.
After a quick look at RFC I wrote down what should be done to make Java server as browser. Kindly help me to complete list below.
Implement STUN server. Server should be abke to respond binding
request and keep-alive pings.
Implement DTLS protocol along with DTLS handshake. After the DTLS
handshake shared secret will be used as keying material within SRTP
and SRTCP.
Support multiplexing of SRTP and SRTCP stream. SRTP and SRTCP use
same port to adress NAT issue.
Not sure whether should I implement SRTCP. I believe connection will
not be broken, if server does not send SRTCP reports to client.
Decode SRTP stream to RTP.
Questions:
Is there anything else which should be done on server-side ?
How webRtc handles SRTCP reports ? Does it adjust sample rate/bit
rate depends on SRTCP report?
WebRtc claims that following issues will be addressed:
packet loss concealment
echo cancellation
bandwidth adaptivity
dynamic jitter buffering
automatic gain control
noise reduction and suppression
Is is webRtc internals or codec(Opus) internals? Do I need to do anything on server side to handle this issues, for example variable bitrate etc ?
The first step would be to implement Interactive Connectivity Establishement (RFC 5245). Whether you make use of a STUN/TURN server or not is irrelevant, your code needs to issue connectivity checks (which use STUN messages) to the browser and respond to the brower's connectivity checks. ICE is a fairly complex state machine, but it's doable.
You don't have to reinvent the wheel. STUN / TURN servers are external components. Use as they are. WebRTC source code is available which you can use in your application code and call the related methods.
Pls. refer to similar post - Server as WebRTC data channel peer
I'm trying to create a generic TLS over TCP socket in C++, using Openssl. The socket would be used in programs running a select loop and utilizing non-blocking I/O.
I'm concerned about the case where the underlying TCP socket becomes readable after the previous SSL_get_error call returned SSL_ERROR_WANT_WRITE. I can think of two situations where this may occur:
The local application and remote application simultaneously decide to send large amounts of data. Both applications call SSL_write simultaneously and subsequent SSL_get_error calls on both applications return SSL_ERROR_WANT_WRITE. The TCP packets sent from both applications cross on the wire. The local application's TCP socket is now readable after the previous SSL_get_error call returned SSL_ERROR_WANT_WRITE.
As above, except the remote Openssl library decides to perform SSL re-negotiation in the SSL_write call, prior to writing any application data. This simply changes the meaning of the data received on the local application's TCP socket from encrypted application data to session re-negotiation data.
How should the local application handle this data? Should it:
call SSL_write as it is currently mid-write?
call SSL_read as would happen if the socket is idle?
SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE can be caused by (re)negotiations or full socket buffers and can not only occure within SSL_read and SSL_write but also SSL_connect and SSL_accept on non-blocking sockets. All you have to do is to wait for the wanted socket state (e.g. readable or writable) and then repeat the same operation. E.g. if you get an SSL_ERROR_WANT_READ from SSL_write you wait until the socket gets readable (with select, poll or similar) and then call SSL_write again. Same with SSL_read.
It might also be useful to use SSL_CTX_set_mode with SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER|SSL_MODE_ENABLE_PARTIAL_WRITE .