China
Africa
Explore chapters and articles related to this topic
Media Channel Control Framework
Published in Radhika Ranjan Roy, Handbook on Networked Multipoint Multimedia Conferencing and Multistream Immersive Telepresence using SIP, 2020
When a TLS client establishes a connection with a server, it is presented with the server’s X.509 certificate. Authentication proceeds as described in RFC 8446 (obsoleted RFC 5246) and in Section 7.3 (“Client Behavior”) of RFC 5922. A TLS server conformant to this specification must ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 (“Server Behavior”) of RFC 5922.
Security Mechanisms in SIP
Published in Radhika Ranjan Roy, Handbook on Session Initiation Protocol, 2018
A TLS server conformant to this specification must ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in RFC 5922 (see Section 19.4.6). If the client does not present a certificate, the server must proceed as if the alias header field parameter was not present in the topmost Via header. In this case, the server must not update the alias table.
Wireless Security Wi-Fi
Published in Ali Youssef, Douglas McDonald II, Jon Linton, Bob Zemke, Aaron Earle, Wi-Fi Enabled Healthcare, 2014
Ali Youssef, Douglas McDonald II, Jon Linton, Bob Zemke, Aaron Earle
One of the main advantages of PEAP is the ability to have a strong EAP type that does not require client certificates like EAP-TLS. PEAP works similarly to EAP-TLS by creating an encrypted tunnel with TLS and then performing another EAP method inside this encrypted tunnel. Unlike EAP-TLS when PEAP performs this process, it does not validate a client certificate. This is where Cisco and Microsoft differ; each of them uses a different method after the TLS connection is created.
Policy-based security for distributed manufacturing execution systems
Published in International Journal of Computer Integrated Manufacturing, 2018
Octavian Morariu, Cristina Morariu, Theodor Borangiu
Client 2: The client sends the CERTIFICATE command, sending its certificate to the server. The server will validate the client certificate against the truststore, check the hostname against the client certificate CN and the CRL from the CA.
MQTT Vulnerabilities, Attack Vectors and Solutions in the Internet of Things (IoT)
Published in IETE Journal of Research, 2023
Ahmed J. Hintaw, Selvakumar Manickam, Mohammed Faiz Aboalmaaly, Shankar Karuppayah
The current MQTT implementation verifies only simple security objects such as identity, authentication, and authorization policies [75]. Identity in MQTT states that the IoT node has the rights to access. Authentication gives the node identity and it confirms whether a node has rights to access. The client can set these policies by utilizing the username/password for specifying the identity or through SSL protocol which validates the client certificate in the MQTT server. IP address, as well as the digital certificate of the MQTT broker/server, is used to identify the MQTT broker/server. Encrypted communication is not given by the MQTT protocol itself. MQTT brokers provide the authorization security objects that restrict the connection only for the authorized client and rules control the node to publish or subscribe to the authorized topics. MQTT has various authentication and data encryption protection mechanisms [29] that are not supported and/or configured by default. However, the security of the MQTT protocol is based on a non-encryption authentication mechanism [24,86]. Sensitive data can be extracting from data in-transit by an attackers through traffic analysis. Information such as public IP address of the MQTT broker, Port number, and payload data of the nodes are mostly targeted by the sniffing attacks. list of threats that could be targeting MQTT due to its security gaps are detailed below [29]. Data Privacy: MQTT has no embedded mechanism for data encryption, by default. Whatever the authentication method is used by the broker or not, when data is transmitted between the broker and MQTT node the data still can be sniffed by the intruder.Authentication: The traffic can be sniffed by the intruder via publisher “Connect” packet node if intruder with publisher are at the same network. The username and password which will be utilized to make connection with broker are existing in such packet. In addition, “Keep Alive” packet can be tracked by the intruder. MQTT header is attached in this packet during the process of the authentication which indicates how long the MQTT broker connection will remain with IoT node. Consequently, the connection will be restarted after time expires and the resend “Connect” packet is initiated.Data integrity: Data could be altered while transmitting from publisher and subscriber by the intruders. After the ARP poisoning is successfully executed is performed, the packages could be altered via utilizing compiled filter by the intruders to make the network connection pass via the node of intruders.Botnet Over MQTT: In this scenario, Shodan search engine utilized by the intruder to search for a device which is to act as broker. Next, free broker server used by the intruder to redirect the victim’s node to it. In this case, “unsecured” broker utilized by intruder as intermediate to build an IoT botnet.