Should gpg try to connect to TCP/993?

[Mikhail Morfikov]

Let's assume you are right, and it's because of the way the linux works.

When I clear the conntrack table, the following messages appear in the FW log
(I don't block the gpg packets for now, just log and accept them in its rule):

  Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \
   SRC=192.168.1.150 DST=64.233.165.108 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=63468 DF PROTO=TCP \
   SPT=41414 DPT=993 SEQ=50635057 ACK=2111326021 WINDOW=501 RES=0x00 ACK PSH URGP=0 \
   OPT (0101080A1268C9EA725E3175) UID=1000 GID=1000
  Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \
   SRC=192.168.1.150 DST=64.233.165.108 LEN=86 TOS=0x00 PREC=0x00 TTL=64 ID=29858 DF PROTO=TCP \
   SPT=41416 DPT=993 SEQ=4217185545 ACK=3828226663 WINDOW=501 RES=0x00 ACK PSH URGP=0 \
   OPT (0101080A1268CA10E67D9F27) UID=1000 GID=1000
  Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \
   SRC=192.168.1.150 DST=64.233.165.108 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35167 DF PROTO=TCP \
   SPT=41510 DPT=993 SEQ=2292653331 ACK=2720180704 WINDOW=501 RES=0x00 ACK PSH URGP=0 \
   OPT (0101080A1268CAFEB48EC039) UID=1000 GID=1000

So it's an ACK packet (possibly one per already opened connection, since 
src ports differ), and not SYN. So it's not a new connection for sure. 
Also, someone once gave me the following audit rule:

  -a exit,always -F arch=b64 -S connect -k MYCONNECT

to find what actually is trying to connect to the net. Each time I see some
blocked OUTPUT packets in the FW logs, I usually run `audit` to find out what
that might be. In all cases so far, in the audit log I was able to match the
dst IP or dst port that I saw in the FW logs. But in the case of gpg, there's
no entry that would match anything that was printed above. So will this match to
your idea?


> The way processes are spawned on Unix, fork()/exec() will by
> default inherit open file descriptors. Thunderbird/Enigmail will
> fork()/exec() to launch gpg.
> 
> Each active TCP/IP connection has an open file descriptor. So, if
> Enigmail's gpg launcher hasn't taken care to close unneeded file
> descriptors after fork() and before exec(), gpg will inherit the
> connections Thunderbird had open at the time of invocation.
Should the `Enigmail's gpg launcher` take care of that? Maybe is a 
bug or something?

> Since gpg doesn't actually know anything about these connections,
> it likely won't close them, they'll stay open (potentially even
> after Thunderbird has closed them, although that doesn't match
> all the symptoms you've described).
So what doesn't match the symptoms I've described? Maybe I have to
pay attention to certain things, and than it will match.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191023/cde707ac/attachment.sig>