Is it possible if I have a tcpdump set up at the gateway of the company LAN, such that all incoming and outgoing traffic is captured, that someone can decrypt the encrypted payload of https packets ? if so, what tools are used to decrypt the payloads of the packets ?
Thanks
-SF
Generally this is not possible unless you have the NSA or the keys at your disposal. But if you do (have the keys), Wireshark can help,
The SSL dissector is fully functional and even supports advanced features such as
decryption of SSL if the encryption key can be
provided and Wireshark is compiled against GnuTLS (rather than OpenSSL
or bsafe). This works for RSA private keys.
http://wiki.wireshark.org/SSL
Related
I'm trying to collect information from the Exchange protocol logs to identify systems using outdated TLS 1.0 before upgrading from 2016 to Exchange 2019. I am able to use get-childitem and select-string to search the smtpreceive log files for the SP_PROT_TLS1_0_SERVER string, however what I would ultimately like to do would be to search the Exchange smtpreceive transport logs for the string SP_PROT_TLS1_0_SERVER. From the hits for SP_PROT_TLS1_0_SERVER, I would like to use the session-id to collect EHLO and MAIL FROM information and record all three values in a csv file so they can be verified in the transport logs for accuracy. So far I've tried to load all fields of the smtpreceive files into a variable, but something's not right and I'm not getting any output.
You would need to trawl through Exchange Protocol Logs Scanning for sent and received traffic (Mail Flow via SMTP Logging)
Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using Ithttps://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-2-enabling-tls-1-2-and/ba-p/607761
Exchange Server: Search message tracking logs https://learn.microsoft.com/en-us/Exchange/mail-flow/transport-logs/search-message-tracking-logs?view=exchserver-2019
Analyzing the protocol logs and Message tracking logs in Exchange 2013 https://social.technet.microsoft.com/wiki/contents/articles/23182.analyzing-the-protocol-logs-and-message-tracking-logs-in-exchange-2013.aspx
Example entries from Exchange Server 2010
A server sending mail to another system using TLS 1.2:
2018-02-22T13:53:10.494Z,<CONNECTORNAME>,08D578EB9C3F6C39,28,10.0.0.240:15443,192.168.1.42:25,*,,"TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 384 bits"
A server receiving mail from another system using TLS 1.2
2018-02-22T13:50:37.681Z,SERVERNAME\CONNECTORNAME Internet,07C578BB0E912319,22,10.0.0.241:25,192.168.1.102:63767,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 256 bits"
SMTP Log Parsing Script WebSites
https://scriptolog.blogspot.com/2007/08/smtp-log-parsing.html
https://www.axigen.com/community/t/made-a-powershell-script-to-parse-smtp-receiving-log/512
I am using WWW::Mechanize module in perl to create a script which goes to another website and downloads data. When I manually go to website and download data (using firefox browser) I can capture the packets in well-readable format using http-fox addon.
But, when I run perl script doing same thing and try to capture packets using Wireshark I can not understand how to understand the captured packets. All the information which was available in above diagram (firefox) is missing in wireshark.
Also, when I click "follow-stream". I get dotted text. Like this:
How to interpret this? May be the data is encrypted. In this case how to get the RSA key?
May be the data is encrypted
The packets in the TCP connection before packet 8 are to or from the "https" port (port 443), and packets 5 and 6 are a "TLSv1 Client Hello" and a "TLSv2 Server Hello", respectively, so this is HTTP-over-TLS traffic, which is likely to be encrypted.
Your browse is probably logging decrypted HTTP-over-SSL traffic in the http-fox module, but Wireshark is capturing the traffic going on the network, which is encrypted traffic.
See the Wireshark Wiki page on SSL for some information on how to have Wireshark decrypt that traffic in some cases.
SMTP allows unecrypted communication over port 25. For some servers (like Google's MX servers) I'm able to switch to a TLS connection using STARTTLS after making the initial unencrypted connection.
S:220 mx.google.com ESMTP l1si352658een.133
C:EHLO mail.example.com
S:250-mx.google.com at your service
S:250-SIZE 35882577
S:250-8BITMIME
S:250-STARTTLS
S:250-ENHANCEDSTATUSCODES
S:250 PIPELINING
C:STARTTLS
S:220 2.0.0 Ready to start TLS
[socket switches to TLS here]
C:EHLO mail.example.com
...
However, I would also like to support straight SSL connections and I'm wondering whether most mail servers prefer starting with SSL or starting with TCP and then moving to TLS after a connection is made.
Unless you have prior arrangements with the administrator of a sever, don't try to connect using SSL. Port (465) was used for SSMTP or SMTPS (SMTP over SSL). Connections to this port were expected to start the connecton with SSL. Use of this port and protocol has been abandoned now that StartTLS is available.
There are two ports which may support SMTP with StartTLS. Neither are expected to support SSL without StartTLS, and will likely drop the connection if you try. Both the SMTP (25) and Submission (587) may support StartTLS. If it is supported, it wlll be listed in the response to an EHLO message. You can then initiate the StartTLS process. See RFC 3207 for more details.
It appears from your comments, that your real concern is how to verify the certificate. That is a different but related question. It also assumes that mail servers are not using self-signed certificates. In my case, I use a self-signed certificate. This works well for me as StartTLS is rarely, if ever, used for SMTP (port 25) connections. I have reasonable control over the clients connecting for message Submission (port 587 or port 25) that must authenticate before sending messages. In my experience, StartTLS is mainly used to secure the connection for clients that must authenticate before sending email.
The support for SSL/TLS on connect (SMTPS) or SSL/TLS after STARTTLS really varies from one server to another, depending on the software and how they've been configured.
The main advantage of SSL/TLS on connect is that it doesn't require any changes in the application protocol. In fact, you could wrap the connection using something like stunnel on each side.
The main advantage of SSL/TLS after STARTTLS is that it can be done on the same port. Another advantage could be to be able to host multiple host names (replacing the need for Server Name Indication at the TLS level), but I'm not sure this has ever been used for SMTP servers.
STMPS (SSL/TLS on connect) doesn't have an official specification and uses a port number for which it is not registered (465). It's also deprecated, in theory. Yet, a number of servers can support it (e.g. Exim) and will be able to support both if they are able to do so: it will be up to the hosting service to choose what to configure.
If you're writing a client and already have support for STARTTLS, it should be fairly cheap to support SSL/TLS upon connect too. It's certainly a good idea to support both, since it will be usable by a wider number of users (if I remember correctly, Gmail used to support only SMTPS at some point, and it can also be useful in case of a firewall that would block one of the ports only).
Both can offer similar levels of security, as long as SSL/TLS is used, one way or another (and that proper certificate verification, including host name, is performed).
There is generally some confusion regarding the difference between SSL and TLS. For some reason, it seems that a number of e-mail software implementations failed to realise that the most important word in "STARTTLS" is "START", not TLS (in terms of connection mode and protocol choice). This confusion has unfortunately propagated to some software configuration options (even in popular mail clients) and thus in ISP documentations. Expect your users to be confused.
Whichever mode you want to support, make sure it doesn't have a "Use TLS, if available" option, which would fall back to a plain exchange if SSL/TLS wasn't available: this opens the connections to MITM attacks.
I use a SIP server that listens over port 5070 for SIP/TLS requests. I'm trying to trace and analyze why my dialer is not registering over the network through Wireshark.
I've edited all the needed fields in Wireshark's preferences, added the server's private key, edited the SIP TCP and TLS ports (which are 5070 not 5061), and all I'm getting now clearly is the TLS Client Hello and Server responses, but no SIP is showing up, just TCP SYNs and ACKs.
I've searched and tried everything possible, but to no avail - any help would be highly appreciated.
Thanks in advance.
//M
Is the TLS session using a cipher suite with perfect forward secrecy? If that is the case, Wireshark cannot decrypt TLS even with the server private key. Check the cipher suite selected by the server in the ServerHello message for the substring EDH or EECDH, in which case perfect forward secrecy is used. You will have do configure the cipher suites in either the client or the server to not use any EDH and EECDH suites. With OpenSSL, use a cipher suite setting of ALL:-EDH:-EECDH or similar.
With perfect forward secrecy, the client and the server will agree on a shared session key using Diffie-Hellman (DH); the server private key is only used for signing. Without perfect forward secrecy, the shared key is encrypted with the server's public key by the client, and thus can be decrypted by the server (and Wireshark) using the server's private key (assuming the server uses an RSA key).
I'm connected to a network that sends and receives a bunch of data packets, but these packets are visible to others (can be sniffed) so I want to tunnel them. I don't know how! I know about socket programming, proxies, vpns, all of the protocols like PPTP, SSH, SSL, TLS, etc. I'm looking for the actual CODE that takes the packages before they're sent,*sends them by tunneling (encapsulating the data)*
How can I do this?
Any information regarding this subject or how to tunnel is appreciated!
Use ssh and socks proxy:
ssh -D 5000 remotehost.com
Then, while your SSH session is alive, you can configure your local apps (such as your web browser) to use this connection as an encrypted tunnel. Just configure them use use localhost:5000 as the socks proxy server, and you're good to go. Note that the packets will only be encrypted between your client and the remote ssh server - once they leave the server, they will be in whatever form they usually are.
If you are on windows, you can do with with putty.