{"id":9375,"date":"2022-09-20T21:54:00","date_gmt":"2022-09-21T02:54:00","guid":{"rendered":"https:\/\/www.rushworth.us\/lisa\/?p=9375"},"modified":"2022-09-22T22:09:26","modified_gmt":"2022-09-23T03:09:26","slug":"elastalert2-ssl-with-opensearch-2-x","status":"publish","type":"post","link":"https:\/\/www.rushworth.us\/lisa\/?p=9375","title":{"rendered":"ElastAlert2 SSL with OpenSearch 2.x"},"content":{"rendered":"\n<p>This turned out to be one of those situations where I went down a very complicated path for a very simple problem. We were setting up ElastAlert2 in our OpenSearch sandbox. I&#8217;ve used both the elasticsearch-py and opensearch-py modules with Python 3 to communicate with the cluster, so I didn&#8217;t anticipate any problems. <\/p>\n\n\n\n<p>Which, of course, meant we had problems. A very cryptic message: <\/p>\n\n\n\n<p class=\"has-small-font-size\">javax.net.ssl.SSLHandshakeException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size<\/p>\n\n\n\n<p>A quick perusal of the archive of all IT knowledge (aka Google) led me to a Java bug: <a rel=\"noreferrer noopener\" href=\"https:\/\/bugs.openjdk.org\/browse\/JDK-8221218\" target=\"_blank\">https:\/\/bugs.openjdk.org\/browse\/JDK-8221218<\/a> which may or may not be resolved in the latest OpenJDK (which we <em>are<\/em> using). I say may or may not because it&#8217;s <em>marked<\/em> as resolved in some places but people report experiencing the bug after resolution was reported. <\/p>\n\n\n\n<p>Fortunately, the OpenSearch server reported something more useful:<\/p>\n\n\n\n<p class=\"has-small-font-size\">[2022-09-20T12:18:55,869][WARN ][o.o.h.AbstractHttpServerTransport] [UOS-OpenSearch.example.net] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=\/10.1.2.3:9200, remoteAddress=\/10.1.2.4:55494}<br>io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL\/TLS record: 504f5354202f656c617374616c6572745f7374617475735f6572726f722f5f646f6320485454502f312e310d0a486f73743a20<\/p>\n\n\n\n<p>Which I&#8217;ve shortened because it was several thousand fairly random seeming characters. Except they <em>aren&#8217;t<\/em> random &#8212; that&#8217;s the communication <em>hex encoded<\/em>. Throwing the string into a hex decoder, I see the HTTP POST request. <\/p>\n\n\n\n<p>Which &#8230; struck me as rather odd because it should be SSL encrypted rubbish. Turns out use_ssl was set to False! Evidently attempting to send clear text &#8216;stuff&#8217; to an encrypted endpoint produces the same error as reported in the Java bug. <\/p>\n\n\n\n<p>Setting use_ssl to true brought us to another adventure &#8212; an SSLCertVerificationError. We have set the verify_certs to false &#8212; even going so far as to go into util.py and modifying line 354 so the <em>default<\/em> is False. No luck. But there&#8217;s another config in each ElastAlert2 rule &#8212; <a rel=\"noreferrer noopener\" href=\"https:\/\/elastalert2.readthedocs.io\/en\/latest\/ruletypes.html#http-post\" target=\"_blank\">http_post_ignore_ssl_errors<\/a> &#8212; that actually does ignore certificate errors. One the rules were configured with http_post_ignore_ssl_errors, ElastAlert2 was able to communicate with the OpenSearch cluster and watch for triggering events. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>This turned out to be one of those situations where I went down a very complicated path for a very simple problem. We were setting up ElastAlert2 in our OpenSearch sandbox. I&#8217;ve used both the elasticsearch-py and opensearch-py modules with Python 3 to communicate with the cluster, so I didn&#8217;t anticipate any problems. Which, of &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1588],"tags":[1590,578,1743,1740,236],"class_list":["post-9375","post","type-post","status-publish","format-standard","hentry","category-elk","tag-elasticsearch","tag-java","tag-jdk","tag-opensearch","tag-ssl"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/9375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9375"}],"version-history":[{"count":1,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/9375\/revisions"}],"predecessor-version":[{"id":9376,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/9375\/revisions\/9376"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}