Databases Reference
In-Depth Information
BEFORE+ACCEPT, OK+ACCEPT,
SR_CLNT_HELLO, SW_SRVR_HELLO, SW_CERT, SW_KEY_EXCH,
SW_CERT_REQ, SW_SRVR_DONE, SW_FLUSH,SR_CERT,
SR_CLNT_HELLO, SW_SRVR_HELLO, SW_CERT, SW_KEY_EXCH,
SW_CERT_REQ, SW_SRVR_DONE, SW_FLUSH,SR_CERT,
SR_KEY_EXCH, SR_CERT_VRFY, SR_FINISHED, SW_CHANGE, SW_FINISHED,
SW_FLUSH, OK
(a) Server trace
BEFORE+CONNECT, OK+CONNECT, CW_CLNT_HELLO,
CR_SRVR_HELLO,CR_CERT, CR_KEY_EXCH, CR_CERT_REQ,CR_SRVR_DONE,
RENEGOTIATE
,
BEFORE, CONNECT, BEFORE+CONNECT, OK+CONNECT, CW_CLNT_HELLO,
CR_SRVR_HELLO, CR_CERT, CR_KEY_EXCH, CR_CERT_REQ, CR_SRVR_DONE,
CW_KEY_EXCH, CW_CHANGE, CW_FINISHED, CW_FLUSH, CR_FINISHED, OK
(b) Client trace
FIGURE 8.31: Traces generated with a faulty OpenSSL client.
normal handshake process) instead of
CW CERT
after reading the five mes-
sages from server (
ServerHello
,
Certificate,
,
ServerKeyExchange
,
CertificateRequest,
,
and
ServerHelloDone
). Then, the client starts the handshake again by sending
the
ClientHello
message, which causes the server to repeat the
hello
stage of
the handshake again. If a client always changes its state to
renegotiate
after
receiving the
ServerHelloDone
message, the server and the client will enter an
infinite loop.
Suspecting this could be exploited in a denial of service (DOS) attack, we
contacted the OpenSSL developers. They argued that it did not indicate a
serious DOS vulnerability because the server looped infinitely only when an
ill-behaved client kept sending renegotiation requests. This was similar to too
many clients attempting to connect to a server, which was a scenario that could
not really be prevented at the server. Although this was not a real vulnerabil-
ity, it did reveal an interesting aspect of OpenSSL, which was not documented
in the SSL specification and was not obvious from code inspection.
Segmentation faults. There were three traces that included segmenta-
tion faults in all versions prior to 0.9.7d. These traces were from the faulty
client that sent a
change cipher spec
instead of the normal
client hello
message
at the beginning of the handshake process. We examined the change log for
version 0.9.7d and found that this was due to a critical update [64], where
an assignment to a null-pointer in the
do change cipher spec
function caused
the server to crash. Although this finding did not result from comparing the
inferred temporal properties, it shows that using randomly behaving clients
to test a server is powerful enough to uncover important problems.
Faulty clients with other errors. For all versions, Perracotta inferred
the same temporal properties for traces within this category. This demon-
strated that the server handled misbehaving clients consistently with respect
to the properties Perracotta inferred.
Search WWH ::
Custom Search