# [Portage] It doesn't recognize the certificate

## azemilian

Hi guys,

I need a help...I've a Check Point Firewall in my network doing the filtering of data. When I try to emerge dev-ruby/minitest-5.8.4, I've been receiving the error below:

```
[ebuild  N     ] dev-ruby/minitest-5.8.4:5::gentoo  USE="-doc {-test}" RUBY_TARGETS="ruby21 ruby22 (-ruby23)" 71 KiB

Total: 1 package (1 new), Size of downloads: 71 KiB

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-ruby/minitest-5.8.4::gentoo

>>> Downloading 'http://distfiles.gentoo.org/distfiles/minitest-5.8.4.gem'

--2017-08-22 16:16:07--  http://distfiles.gentoo.org/distfiles/minitest-5.8.4.gem

Resolving distfiles.gentoo.org... 64.50.233.100, 137.226.34.46, 140.211.166.134, ...

Connecting to distfiles.gentoo.org|64.50.233.100|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 72192 (70K) [application/x-troff-man]

Saving to: ‘/usr/portage/distfiles/minitest-5.8.4.gem’

/usr/portage/distfi  99%[==================> ]  70.42K   245KB/s    in 0.3s

2017-08-22 16:16:09 (245 KB/s) - Read error at byte 72113/72192 (Connection reset by peer). Retrying.

--2017-08-22 16:16:10--  (try: 2)  http://distfiles.gentoo.org/distfiles/minitest-5.8.4.gem

Connecting to distfiles.gentoo.org|64.50.233.100|:80... connected.

HTTP request sent, awaiting response... 307 Temporary Redirect

Location: http://172.22.1.1/UserCheck/PortalMain?IID=56246B87-BC2C-F481-4FD7-2EA2D7DD1896&origUrl=aHR0cDovL2Rpc3RmaWxlcy5nZW50b28ub3JnL2Rpc3RmaWxlcy9taW5pdGVzdC01LjguNC5nZW0 [following]

--2017-08-22 16:16:10--  http://172.22.1.1/UserCheck/PortalMain?IID=56246B87-BC2C-F481-4FD7-2EA2D7DD1896&origUrl=aHR0cDovL2Rpc3RmaWxlcy5nZW50b28ub3JnL2Rpc3RmaWxlcy9taW5pdGVzdC01LjguNC5nZW0

Connecting to 172.22.1.1:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: ‘/usr/portage/distfiles/minitest-5.8.4.gem’

/usr/portage/distfi     [ <=>                ]  98.19K  --.-KB/s    in 0.008s

2017-08-22 16:16:10 (11.8 MB/s) - ‘/usr/portage/distfiles/minitest-5.8.4.gem’ saved [100551]

!!! Fetched file: minitest-5.8.4.gem VERIFY FAILED!

!!! Reason: Filesize does not match recorded size

!!! Got:      172664

!!! Expected: 72192

Refetching... File renamed to '/usr/portage/distfiles/minitest-5.8.4.gem._checksum_failure_.ykaiuixz'

>>> Downloading 'https://rubygems.org/gems/minitest-5.8.4.gem'

--2017-08-22 16:16:10--  https://rubygems.org/gems/minitest-5.8.4.gem

Resolving rubygems.org... 151.101.194.2, 151.101.2.2, 151.101.130.2, ...

Connecting to rubygems.org|151.101.194.2|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 72192 (70K) [binary/octet-stream]

Saving to: ‘/usr/portage/distfiles/minitest-5.8.4.gem’

/usr/portage/distfi  89%[================>   ]  63.16K  --.-KB/s    in 0.02s

2017-08-22 16:16:11 (3.10 MB/s) - Connection closed at byte 64674. Retrying.

--2017-08-22 16:16:12--  (try: 2)  https://rubygems.org/gems/minitest-5.8.4.gem

Connecting to rubygems.org|151.101.194.2|:443... connected.

HTTP request sent, awaiting response... 307 Temporary Redirect

Location: http://172.22.1.1/UserCheck/PortalMain?IID=9C94C883-CA6A-5F82-3ECE-F8BD8470A5DF&origUrl=aHR0cHM6Ly9ydWJ5Z2Vtcy5vcmcvZ2Vtcy9taW5pdGVzdC01LjguNC5nZW0 [following]

--2017-08-22 16:16:12--  http://172.22.1.1/UserCheck/PortalMain?IID=9C94C883-CA6A-5F82-3ECE-F8BD8470A5DF&origUrl=aHR0cHM6Ly9ydWJ5Z2Vtcy5vcmcvZ2Vtcy9taW5pdGVzdC01LjguNC5nZW0

Connecting to 172.22.1.1:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: ‘/usr/portage/distfiles/minitest-5.8.4.gem’

/usr/portage/distfi     [ <=>                ]  98.19K  --.-KB/s    in 0.008s

2017-08-22 16:16:13 (11.3 MB/s) - ‘/usr/portage/distfiles/minitest-5.8.4.gem’ saved [100551]

!!! Fetched file: minitest-5.8.4.gem VERIFY FAILED!

!!! Reason: Filesize does not match recorded size

!!! Got:      165225

!!! Expected: 72192

Refetching... File renamed to '/usr/portage/distfiles/minitest-5.8.4.gem._checksum_failure_.hjyllwiu'

!!! Couldn't download 'minitest-5.8.4.gem'. Aborting.

 * Fetch failed for 'dev-ruby/minitest-5.8.4', Log file:

 *  '/var/tmp/portage/dev-ruby/minitest-5.8.4/temp/build.log'

>>> Failed to emerge dev-ruby/minitest-5.8.4, Log file:

>>>  '/var/tmp/portage/dev-ruby/minitest-5.8.4/temp/build.log'

 * Messages for package dev-ruby/minitest-5.8.4:

 * Fetch failed for 'dev-ruby/minitest-5.8.4', Log file:

 *  '/var/tmp/portage/dev-ruby/minitest-5.8.4/temp/build.log'

```

I already have been placed the certificate in /usr/local/share/ca-certificates provided for my Network Admin:

```
localhost ca-certificates # pwd

/usr/local/share/ca-certificates

localhost ca-certificates # ls

https_certificate.crt
```

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## Hu

Your network firewall is doing an active Man In the Middle attack.  That is bad.  Tell your network administrator to cut it out.  An active TLS intercept like that prevents the client application from properly validating the actual TLS connection with the real peer, leaving you dependent on your snooping box to verify that the upstream connection is not subverted.  My experience has been that TLS snoopers are rather unreliable about that.  Your best bet by far is to use TLS as intended.  Switch the device to HTTPS proxy mode, where clients tell it to what server they wish to connect, optionally authenticate, and are then given a clean tunnel to negotiate TLS with the peer.

As for your immediate problem, the attacker box is stupidly trying to be an interactive captive portal for a non-interactive connection.  This is broken, wrong, and disgustingly common.  Tell your network administrator to cut that out, too.  Not all HTTP clients are interactive web browsers.  You might be able to work around this by authenticating to the attacker box first, assuming its authentication is done at a level that other HTTP applications on your computer will automatically benefit from.Last edited by Hu on Fri Aug 25, 2017 1:42 am; edited 2 times in total

----------

## Ant P.

There's no HTTPS or certificates involved here. The portage mirror is being accessed over HTTP, something on your network is intercepting that and serving crap instead of the requested file.

----------

## Syl20

... Or just an error page. Did you try to file/cat the downloaded file ?

----------

## Hu

Ant P.: not quite: *azemilian wrote:*   

> 
> 
> ```
> --2017-08-22 16:16:12--  (try: 2)  https://rubygems.org/gems/minitest-5.8.4.gem
> 
> ...

 Some of his downloads were http, but one attempt to fetch it over https instead got a redirect to an internal HTTP page.  That looks to me like a captive portal gone wrong.  Disabling TLS interception (at least on the client by not whitelisting the attacker box, but preferably by getting the network administrator to quit screwing around) likely would have avoided this.  If the network administrator does not want outbound connections, he should be blocking them explicitly, not transparently mangling them.  Returning an interactive captive portal page in place of a binary file served to a non-interactive http client is a particularly obnoxious bit of mangling.

Syl20: it probably is a captive portal page.  I would be wary of using cat on the downloaded contents, as it might contain characters that would mangle terminal state.  A graphical text editor such as gvim would be safer, although less with the right options should be fine too.

----------

## Ant P.

Didn't spot that, good eye... this makes things a bit worse, because it's accepting a MITM but attacking anyway, and worse it's downgrading to HTTP after allowing half a good connection through (with headers intact, presumably HSTS ones too, so any site using those will become inaccessible).

Sounds like a PEBKAC in the server room. Like Hu says, a properly configured security appliance would never behave this badly.

----------

## Hu

Decoding the text of the origUrl CGI parameter gives the URL that was intercepted, so it might work if the user satisfies the device's captive portal logic.  The problem is that captive portals are almost always implemented stupidly, such that satisfying it for automated downloaders is a pain.  In my opinion, if intercepting the connection is unavoidable, the network (in)security box should recognize non-interactive clients and serve to them a hard error page, including an HTTP error code, so that they do not (as in this case) mistake the captive portal page as the desired download.

----------

