Planning-Based Security Testing of the SSL/TLS Protocol

Automated planning for finding alternative bug traces

“…They extend the domain of classical planning with the capability of modelling control systems represented using high‐level specifications. Planning‐based approaches have been introduced for modelling and testing of web applications [25], automated test case generation for security testing of cryptographic protocols SSL/TLS [26, 27], business process management [28] and so on.…”

Testing TLS Using Combinatorial Methods and Execution Framework

“…Since other attributes in these two layers will be determined by values in Message Body, we only need to do IPM on attributes in Message Body for handshake protocol messages. (1) the length of message body in bytes ClientHello server hello (2) the length of message body in bytes ServerHello certificate (11) the length of message body in bytes Certificate server key exchange (12) the length of message body in bytes ServerKeyExchange certificate request (13) the length of message body in bytes CertificateRequest server hello done (14) 0 empty certificate verify (15) the length of message body in bytes CertificateVerify client key exchange (16) the length of message body in bytes ClientKeyExchange finished (20) the length of message body in bytes Finished (255) In this paper, since we only test TLS implementation from client side, IPM is only applied on client-side handshake messages. For example, we do IPM on ClientHello message, but not on ServerHello message.…”

“…First, the order of TLS events can be manipulated, thus deviating from the default sequence. This approach was demonstrated in a simple example in [15]. Another option would be to check the default sequence by manipulating the concrete parameter values of some of the individual TLS events.…”