Unable to generate HTTPS certificate in kali

[nrz123]

my kali version: root@kali:~# uname -a Linux kali 4.19.0-kali5-amd64 #1 SMP Debian 4.19.37-6kali1 (2019-07-22) x86_64 GNU/Linux

now my ettercap version: root@kali:~# ettercap

ettercap 0.8.3 copyright 2001-2019 Ettercap Development Team

the ettercap with kali is 0.8.2,and it can't generate the cert,then i uninstall the software and git the lastest source and make it,but now it can't support the https cert too

and this is my iptables when i start the sniff: root@kali:~# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:telnets redir ports 59263 REDIRECT tcp -- anywhere anywhere tcp dpt:submissions redir ports 59264 REDIRECT tcp -- anywhere anywhere tcp dpt:pop3s redir ports 59265 REDIRECT tcp -- anywhere anywhere tcp dpt:nntps redir ports 59266 REDIRECT tcp -- anywhere anywhere tcp dpt:ldaps redir ports 59267 REDIRECT tcp -- anywhere anywhere tcp dpt:994 redir ports 59268 REDIRECT tcp -- anywhere anywhere tcp dpt:imaps redir ports 59269 REDIRECT tcp -- anywhere anywhere tcp dpt:http-alt redir ports 59270 REDIRECT tcp -- anywhere anywhere tcp dpt:https redir ports 59271 REDIRECT tcp -- anywhere anywhere tcp dpt:ftps redir ports 59272

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain POSTROUTING (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

this is the wireshake picture

and the target1 is 192.168.1.102 the target2 is 192.168.1.1,and my ip is 192.168.1.100 so in the picture we can see before the 119 line it is true,but the line 119 you can see the error,i don't know what is the question

and then my openssl version:

root@kali:~# openssl version OpenSSL 1.1.1c 28 May 2019

you can see my conf

i don't know what's wrong and my mother tongue is not English.There may be a lot of grammatical errors.

[nrz123]

and i have tried uninstall the openssl or upgrade the kali or upgrade the ettercap.but it is also don't work.in kali,i have no idea make it work,whether in command line or in gnome.and the --certificate option can't make it work too this is my command: root@kali:~# ettercap -T -M ARP /192.168.1.102/ /192.168.1.1/ --certificate ./share/etter.ssl.crt root@kali:~# ettercap -T -M ARP /192.168.1.102/ /192.168.1.1/ they are all invalid

[koeppea]

So when I understand you correctly, you intercept HTTPS traffic with ettercap but then the SSL handshake fails. Correct? Please read the newly created Wiki page to provide debug information required to troubleshoot the problem.

[nrz123]

when i get your respones,i have tried reinstall the kali,4.19 amd64,but it is useless,and the i make source iwith debug,this is log ettercap-0.8.3_debug.log i think start with line 671 and the target1 is 192.168.1.102 target2 is 192.168.1.1 my ip is 192.168.1.110 i can't realy understand the log,i hope it can be use

error.tar.gz and this is log and pcap

[nrz123]

from the log i find this code,in the ec_socket.c line 105,in the log there is not error everytime,so is the loop number too small? the error code is EALREADY,but i don't know what's mean

[koeppea]

The retry loops are far enough and extending would also not solve the problem. The problem lies in the ARP poison status of your router: Colored in green is the communication between the victim and the Ettercap. Colored in blue is the communication between Ettercap and your Router.

It tries to establish the connection towards the actual destination with the source IP of your victim and the source MAC of the attacker. However it this connection attempt gets starved.

The reason is, that your router wasn't successfully poisoned and didn't override the ARP entry of the victim. So the SYN,ACK packets will be directed back to your victim directly w/o going over the attacker, but the victim doesn't have a socket for that specific TCP stream.

You can try to tweak ARP spoofing: In the etter.conf play with the parameters arp_poison_warm_up and arp_poison_delay. Alternatively, an not so aggressive but more intelligent method can be tried by setting the following parameters to 1: arp_poison_smart and if this also doesn't help arp_poison_request. Read the etter.conf man page to understand what these parameters are responsible for.

But if your router's ARP cache is really that sticky, there's not much to do. But this is not a problem or bug of Ettercap. Ettercap is working correctly.

[koeppea]

Ah wait a second. The outbound connection that starves out is made from Ettercap's source IP. So it might really be some kind of IPS functionality of your router. So making ARP poison more silent may help here. I assume when Ettercap isn't running, the attacker machine has no issues with Internet connectivity?

[nrz123]

i have tried the smart and the request,but it invalid,and i tried the more set but if ettercap use the attacker ip and attacker mac to get the connect with dst,like a proxy,then it just only need poison the victim.is there this option in ettercap?

[nrz123]

but infact when i found the other tcp packets with the wireshark,i have found many packet that the dst ip is victim and the dst mac is attacker from the router,is it means router is successfully poisoned,

[nrz123]

maybe i can give you the new log error.zip because i find many packet that dst ip is victim and dst mac is attcaker and the src is router,i think it means router is successfully poisoned route ip is 192.168.1.1 mac is 28:2c:b2:4a:31:ec attacker ip is 192.168.1.107 mac is f8:34:41:bb:96:30 victim ip is 192.168.1.105 mac is c4:9f:4c:d1:e0:6c and the log show some different whit the old

[koeppea]

Yes you're right. This debug package contains a better example. I can see now that the attacker can communicate with the outside world, but the attacker aborts the TLS handshake with the victim. I've to try to reproduce..... getting back as soon I've any news.

[nrz123]

when i check the code,i find question in ec_sslwrap.c line 548,SSL_accept failed, and SSL_get_error return 1,when i call the ERR_error_string,the function give the string is "SSL routines:tls_post_process_client_hello:no shared cipher"

[koeppea]

Thanks for the checking. However I don't think that this is related to shared cipher suite, since the server picks a suite in the Server Hello. The handshake failure happens later. What wonders me a bit, is that the first Client Hello from the Victim doesn't contain a Session ID but the spawned Client Hello from the Attacker does have a Session ID.

[koeppea]

Can you compile the pull-request #971 and try if this improves something? First tests on my side look promising.

[koeppea]

I think I've now fixed the SSL problem you're facing. Fix is in PR #971 and contains also some other SSL intercept improvements, tough which may not be relevan for your issue. Can you please test if PR #971 fixes the issue you're experiencing?

[koeppea]

Here is a interception test done using Chrome:

Thu Nov 21 17:58:23 2019 [550273]
TCP  172.21.21.40:58596 --> 154.59.49.3:443 | P (465)
GET /test.txt HTTP/1.1.
Host: myssltest.org.
Connection: keep-alive.
Upgrade-Insecure-Requests: 1.
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/75.0.3770.90 Chrome/75.0.3770.90 Safari/537.36.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3.
Accept-Encoding: gzip, deflate, br.
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7.
.

Thu Nov 21 17:58:23 2019 [624143]
TCP  154.59.49.3:443 --> 172.21.21.40:58596 | P (342)
HTTP/1.1 200 OK.
Date: Thu, 21 Nov 2019 16:58:23 GMT.
Server: Apache/2.4.25 (Debian).
Upgrade: h2,h2c.
Connection: Upgrade, Keep-Alive.
Last-Modified: Sun, 10 Nov 2019 13:27:47 GMT.
ETag: "11-596fdfb2006d6".
Accept-Ranges: bytes.
Content-Length: 17.
Keep-Alive: timeout=5, max=100.
Content-Type: text/plain; charset=UTF-8.
.
Das ist ein Test

As you can see the packet details are displayed in clear text even though it's an connection port 443.

[koeppea]

Closing since fixing PR #971 has been merged