examine remote server certificate on server connection event mitmproxy - mitmproxy

how can i read / examine the remote server certificate during server connection event on regular proxy mode
this is my code :
the cert attribute on documentation state as The certificate presented by the remote during the TLS handshake
import mitmproxy
from mitmproxy import ctx
def serverconnect(conn: mitmproxy.connections.ServerConnection):
ctx.log.info(conn.cert)
the event log info always to none.... thanks for the advice and the answer

Related

ATWINC1500 SSL socket connect aborted

I am currently working with ATWINC1500 wifi network module on their WiFi click7 board which communicate with PIC32 (FreeRTOS Curiosity PIC32MZ EF).
I'm trying to create tls client example (TLS 1.2) using MPLAB Harmony v3. Socket has been opened successfully, I got the hostname and its IP address, but when I call the connect API, I got the SOCKET_MSG_CONNECT callback with error code (connect aborted). it's related to the certificate??
How installing the root certificate of my server in ATWINC1500 using MPLAB harmony v3.
How I can verify that my certificate has been installed
In Harmony 3, I need the setting of cipher suites or they are enabled by default, because I found this API (WDRV_WINC_SSLActiveCipherSuitesSet) but it's not used.
Thanks.

Fiddler 4.6 cannot connect to strong SSL?

Error:
[Fiddler] The connection to '<the site>.com' failed.
System.Security.SecurityException Failed to negotiate HTTPS connection with server.fiddler.network.https> HTTPS handshake to <the site>.com (for #3) failed. System.IO.IOException Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. < An existing connection was forcibly closed by the remote host
I can hit fine in web browser. I do see it is rather strong SSL (FireFox reports it as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2)
Why isn't Fiddler able to make this connection?
Seems that your client didn't try to connect via 1.2
Check: Tools > Fiddler Options > HTTPS
It's set to <client>;ssl3;tls1.0
Add "tls1.2" to the protocols list
Edit:
Refer to the image below for where to find the option:

Testing RADSEC with FreeRadius

I'm new to RADIUS, servers, and the like. There doesn't seem to be that much documentation on FreeRadius, and I need to get FreeRadius server (3.0.8) running RADSEC for test purposes.
I moved etc/raddb/sites-available/tls to etc/raddb/sites-enabled/ in order to enable "RADSEC".
Questions:
I understand that I need to have a server certificate as well as a public key. I am wondering on if I could get a fake certificate/key just for testing.
Also I'm not sure how I can test the actual server, there's the radtest command (I've been trying to run radtest -P tcp -x testing password 127.0.0.1:2083 10 testing123 but it's returns:
... new connection request on TCP socket
Listening on auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Waking up in 0.4 seconds.
(0) Initiating new EAP-TLS session
(0) Setting verify mode to require certificate from client
(0) Non-TLS data sent to TLS socket: closing
Closing TLS socket from client port 40542
Client has closed connection
... shutting down socket auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Waking up in 2.9 seconds.
... cleaning up socket auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Ready to process requests
Do I need to set up another server as a client so that they can perform the TLS negotiation? And once I do that, how do I get that server to communicate with this RADSEC server?
radtest is attempting a non TLS connect to the server. And thats the reason you are seeing that the server disconnects the connection immediately.
You can explore radsecproxy. It supports TLS (RadSec), as well as RADIUS over TCP. So it can happen as intermediary for the non TLS client and TLS server.

SSL Errors when implementing an SSL tunnelling

I'm implementing an SSL tunnelling proxy, just like what Squid proxy's CONNECT tunnel provides
However, I observed that sometimes the SSL connections go through me return SSL Errors.Those errors are: invalid TLS padding, bad record MAC...
My proxy is simple, just read() from downstream socket then write() to upstream socket. (I also implemented data buffering when one of those pair sockets is not writable)
Hope you can help me with this
Edited: Mine is just a tunnel forwarding proxy, I do not intercept the SSL connection between client and server. Just read() then write()

How can I decode SIP/TLS (non default SIPS port) packets through Wireshark?

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).