(http_inspect) UNKNOWN METHOD for SSL over http proxy

[Sss kkk <sk.snort.user () gmail com>]

Hello,

I'm new to snort, running version 2.9.7.2

For http traffic going through the proxy server I'm receiving huge amount
of 'unknown method' (119:31:1) alerts.
It happens for every HTTPS connection going through the proxy server.
There is nothing special in the traffic - simple opening https://github.com
in the browser causes bunch of alerts generated by snort.

Dump captured at the proxy server side and presented in wireshark seems to
be correct:

CONNECT github.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101
Firefox/36.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: github.com:443

HTTP/1.0 200 Connection established

............s.7..~v..J.z....h.=.)..T...k...
.t_..3....-.m'7g..........0..o.....+./.
.......3.2.9./.5.
...x.....
..
github.com......
.................#..3t.....#.!.h2-15.h2-14.h2.spdy/3.1.http/1.1..........
........................l...h..U.B..j.D-.#.;.P.d]r_
....ni\3$.. .T.......v......E.
.4>uH..J.*..../.. ........................http/1.1...
...
..
(...)

Page displays without any errors anyway. The packet above with hex payload
is decoded as "Client Hello" (TLSv1.2) in the Wireshark.

At the same time at the snort I have alert generated for all packets after
"connection established" response.
First one comes for the same payload visible in the dump:

(snorby output):
http_inspect: UNKNOWN METHOD

Src Port        Dst Port        Seq     Ack     Off     Res     Flags
Win     Csum    URP
47100   8080    3070814240      2482041191      8       0       24
229     56036   0

0000000: 16 03 01 00 dd 01 00 00 d9 03 03 fd 73   83 37 ba a9 7e 76 93 9b
4a e3 7a da ff  ............s.7..~v..J.z..
000001A: 19 0e 68 f4 3d 95 29 de 1b 54 bd e8 c5   6b c5 8e f1 20 bf 74 5f
eb b8 33 97 e7  ..h.=.)..T...k.....t_..3..
0000034: f1 ea 2d be 6d 27 37 67 93 b2 0e df b3   b3 f6 ab fd f9 30 ad 97
6f dd 9d 00 18  ..-.m'7g..........0..o....
000004E: c0 2b c0 2f c0 0a c0 09 c0 13 c0 14 00   33 00 32 00 39 00 2f 00
35 00 0a 01 00  .+./.........3.2.9./.5....
0000068: 00 78 00 00 00 0f 00 0d 00 00 0a 67 69   74 68 75 62 2e 63 6f 6d
ff 01 00 01 00  .x.........github.com.....
0000082: 00 0a 00 08 00 06 00 17 00 18 00 19 00   0b 00 02 01 00 00 23 00
00 33 74 00 00  ...................#..3t..
000009C: 00 10 00 23 00 21 05 68 32 2d 31 35 05   68 32 2d 31 34 02 68 32
08 73 70 64 79  ...#.!.h2-15.h2-14.h2.spdy
00000B6: 2f 33 2e 31 08 68 74 74 70 2f 31 2e 31   00 05 00 05 01 00 00 00
00 00 0d 00 12  /3.1.http/1.1.............
00000D0: 00 10 04 01 05 01 02 01 04 03 05 03 02   03 04 02 02
02                          ..................

It is replicable and it always happens for HTTPS going over the http proxy.
There are no timeouts or something.
TCP session from the client to the proxy server has been established just
before CONNECT so should be properly tracked.

I was wondering if it is expected behavior for http_inspect in such a
proxing scenario? Could be I misunderstood something.

Related configuration:

(increased memcap for session tracking, however haven't seen drops due to
this anyway)
preprocessor stream5_global: track_tcp yes, \
   track_udp yes, \
   track_icmp no, \
   memcap 67108864, \
   max_tcp 262144, \
   max_udp 131072, \
   max_active_responses 2, \
   min_response_seconds 5
preprocessor stream5_tcp: policy windows, detect_anomalies, require_3whs
180, \
   overlap_limit 10, small_segments 3 bytes 150, timeout 180, \
    ports client 21 22 23 25 42 53 70 79 109 110 111 113 119 135 136 137
139 143 \
        161 445 513 514 587 593 691 1433 1521 1741 2100 3306 6070 6665 6666
6667 6668 6669 \
        7000 8181 32770 32771 32772 32773 32774 32775 32776 32777 32778
32779, \
    ports both 36 80 81 82 83 84 85 86 87 88 89 90 110 311 383 443 465 563
555 591 593 631 636 801 808 818 901 972 989 992 993 994 995 1158 1220 1414
1533 1741 1830 1942 2231 2301 2381 2809 2980 3029 3037 3057 3128 3443 3702
4000 4343 4848 5000 5117 5250 5600 6080 6173 6988 7907 7000 7001 7071 7144
7145 7510 7802 7770 7777 7778 7779 \
        7801 7900 7901 7902 7903 7904 7905 7906 7908 7909 7910 7911 7912
7913 7914 7915 7916 \
        7917 7918 7919 7920 8000 8008 8014 8028 8080 8081 8082 8085 8088
8090 8118 8123 8180 8181 8222 8243 8280 8300 8333 8344 8500 8509 8800 8888
8899 8983 9000 9060 9080 9090 9091 9111 9290 9443 9999 10000 11371 12601
13014 15489 29991 33300 34412 34443 34444 41080 44449 50000 50002 51423
53331 55252 55555 56712


preprocessor http_inspect: global iis_unicode_map unicode.map 1252
compress_depth 65535 decompress_depth 65535 max_gzip_mem 104857600
proxy_alert
preprocessor http_inspect_server: server default \
    http_methods { GET POST PUT SEARCH MKCOL COPY MOVE LOCK UNLOCK NOTIFY
POLL BCOPY BDELETE BMOVE LINK UNLINK OPTIONS HEAD DELETE TRACE TRACK
CONNECT SOURCE SUBSCRIBE UNSUBSCRIBE PROPFIND PROPPATCH BPROPFIND
BPROPPATCH RPC_CONNECT PROXY_SUCCESS BITS_POST CCM_POST SMS_POST
RPC_IN_DATA RPC_OUT_DATA RPC_ECHO_DATA } \
    chunk_length 500000 \
    server_flow_depth 0 \
    client_flow_depth 0 \
    post_depth 65495 \
    oversize_dir_length 500 \
    max_header_length 1500 \
    max_headers 100 \
    max_spaces 200 \
    small_chunk_length { 10 50 } \
    ports { 36 80 81 82 83 84 85 86 87 88 89 90 311 383 555 591 593 631 801
808 818 901 972 1158 1220 1414 1533 1741 1830 1942 2231 2301 2381 2809 2980
3029 3037 3057 3128 3443 3702 4000 4343 4848 5000 5117 5250 5600 6080 6173
6988 7000 7001 7071 7144 7145 7510 7770 7777 7778 7779 8000 8008 8014 8028
8080 8081 8082 8085 8088 8090 8118 8123 8180 8181 8222 8243 8280 8300 8333
8344 8500 8509 8800 8888 8899 8983 9000 9060 9080 9090 9091 9111 9290 9443
9999 10000 11371 12601 13014 15489 29991 33300 34412 34443 34444 41080
44449 50000 50002 51423 53331 55252 55555 56712 } \
    non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \
    enable_cookie \
    extended_response_inspection \
    inspect_gzip \
    normalize_utf \
    unlimited_decompress \
    normalize_javascript \
    apache_whitespace no \
    ascii no \
    bare_byte no \
    directory no \
    double_decode no \
    iis_backslash no \
    iis_delimiter no \
    iis_unicode no \
    multi_slash no \
    utf_8 no \
    u_encode yes \
    webroot no


proxy_alert added as a try also doesn't raise an alert for https
connections. It works fine and rise alerts (UNAUTHORIZED PROXY USE
DETECTED) for HTTP sessions going through the proxy server. For HTTPS ones
'unknown method' is raised only.

Could someone advise how to get that traffic analyzed without false alarms
and without a need to suppress the inspection.

Best regards,
stan

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!