Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 18198 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RealVNC Viewer, login to RealVNC account CA issue; has anybody come across this and thus know the required filter exceptions?

Briain
Hi

I am using UTM 9.506-2 in Transparent mode, with https traffic being inspected and the CA installed on my various machines and browsers. It all works fabulously well, but I have stumbled across an odd issue that I have not yet figured out. It is not something that I even require, but I am just really curious to know what the solution might be.

I just use RealVNC to access machines (on two different VLANs) on my local network and it all works very well. I don't need it's cloud feature to access machines outside of my internal network, but for my own curiosity, I was trying to get the RealVNC viewer to connect to my RealVNC account, but it just states that there's 'no network' (Linux version) or that it 'Failed to sign in to account due to a network error' (Windows version)

I then created an exception, as shown below:

^https?://([A-Za-z0-9.-]*\.)?realvnc\.com/

That didn't help, so I enabled logging in RealVNC connect, then discovered that it was moaning about my certificate (so the above seems not to have done the job) and looking through the RealVNC log entries (during an attempted login) I noticed several other https URLs listed:

https://hb-b.services.vnc.com
https://hb-a.services.vnc.com
https://hb-c.services.vnc.com
auth-a.services.vnc.com
auth-b.services.vnc.com
auth-c.services.vnc.com

So, I then created the below exception:

^https?://([A-Za-z0-9.-]*\.)?services\.realvnc\.com/

That didn't fix things; it still complains about my certificate, so I am now a little puzzled at what next to try and thus I wondered if anybody else had come across this issue and fixed it? Of course, I can indeed use a browser to log onto the RealVNC site and my exceptions do result in me seeing their certificates (realvnc.com uses Amazon and the login page uses GeoTrust; both are visible via clicking on the Firefox padlock).

As I say, I don't actually have a requirement for RealVNC Viewer to log on (well, certainly not at the moment) so the above question is more just to improve my education (and trust me, it sure does need some considerable improving; likely I am missing something that's blindingly obvious, I reckons )! :-)

All the best Briain

PS Below shows the tail of the RealVNC log file and as you can see, it is seeing my certificate (as opposed to the one from the RealVNC site) so to my understanding, I have not correctly set the web filter bypass for it (by the way, everything is ticked on the above two bypass expressions).

2018-01-19T16:43:03.191Z HP vncviewer[5336]: SslTrustManager: Certificate validation failed for certificate:
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SslTrustManager: Subject = CN=*.services.vnc.com,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT20446643
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SslTrustManager: Issuer = emailAddress=redacted@gmail.com,CN=Briain-redacted Proxy CA,O=Briain-redacted,L=Edinburgh,C=uk
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SslTrustManager: The certificate is not correctly signed by the trusted CA
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SslTrustManager: The certificate is signed with an unacceptable key (eg bad curve, RSA too short).
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SslIo: Handshaking error: X.509 Error: Unknown issuer or bad signature
2018-01-19T16:43:03.191Z HP vncviewer[5336]: FdIo: shutdown 0000026F078096A0 (fd=744), flush true (tellHandler true)
2018-01-19T16:43:03.191Z HP vncviewer[5336]: FdIo: shutdown complete 0000026F078096A0 (fd=744)
2018-01-19T16:43:03.191Z HP vncviewer[5336]: FdIo: shutdown 0000026F078096A0 (fd=744), flush true (tellHandler false)
2018-01-19T16:43:03.191Z HP vncviewer[5336]: HttpRequest: Request failed: Error connecting: X.509 Error: Unknown issuer or bad signature [0000026F077DD830]
2018-01-19T16:43:03.191Z HP vncviewer[5336]: HostedBootstrapInfo: Bootstrap network failure
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SignInOperations: Error authenticating user: Hosted Bootstrap error: Network failure: Error connecting: X.509 Error: Unknown issuer or bad signature
2018-01-19T16:43:03.191Z HP vncviewer[5336]: SignInMgr: Sign-in failed: Hosted Bootstrap error: Network failure: Error connecting: X.509 Error: Unknown issuer or bad signature
2018-01-19T16:43:11.222Z HP vncviewer[5336]: ConfigParameter: unset Log(String) priority 10, now *:stderr:10, priority 0
2018-01-19T16:43:13.988Z HP vncviewer[5336]: Registry: open(80000001,Software,rw) (sam=f003f) = 4b0
2018-01-19T16:43:13.988Z HP vncviewer[5336]: Registry: create(4b0,RealVNC,rw) (sam=f003f) = 4a4
2018-01-19T16:43:13.988Z HP vncviewer[5336]: Registry: create(4a4,vncviewer,rw) (sam=f003f) = 4b0
2018-01-19T16:43:13.988Z HP vncviewer[5336]: ConfigParameter: unset Log(String) priority 10, now *:stderr:10, priority 0


This thread was automatically locked due to age.
Parents
  • 0

    Try

    ^https?://([A-Za-z0-9.-]*\.)?hb-a\.services\.vnc\.com/

    ^https?://([A-Za-z0-9.-]*\.)?hb-b\.services\.vnc\.com/

    ^https?://([A-Za-z0-9.-]*\.)?hb-c\.services\.vnc\.com/

     

  • 0 in reply to PatrickLee
    Hi

    Thank you very much for the suggestions, but unfortunately, I still haven't cracked it. I have made slight progress though; when using the Linux version of RealVNC viewer, I was not seeing anything useful in the web filter logs (I've figured out why, but it is irrelevant so I’ll not go into that here) but trying RealVNC Viewer login on a Windows 10 machine always results in the below sequence of logging events, and tellingly, they occur whether the Sophos web filter exception group is toggled on, or toggled off):

    2018:01:21-09:52:12 hadrian httpproxy[27133]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xa084400" function="ssl_connect" file="ssl.c" line="1576" message="ssl_handshake: Input/output error"
    2018:01:21-09:52:13 hadrian httpproxy[27133]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xd897b000" function="ssl_connect" file="ssl.c" line="1576" message="ssl_handshake: Input/output error"
    2018:01:21-09:52:13 hadrian httpproxy[27133]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xa3cb200" function="ssl_connect" file="ssl.c" line="1576" message="ssl_handshake: Input/output error"
    2018:01:21-09:52:14 hadrian httpproxy[27133]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="read_request_headers" file="request.c" line="1588" message="Read error on the http handler 79 (Input/output error)"
    2018:01:21-09:52:14 hadrian httpproxy[27133]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="read_request_headers" file="request.c" line="1588" message="Read error on the http handler 79 (Input/output error)"

    In my group of RealVNC exceptions, I have tried the below three variants:

    ^https?://([A-Za-z0-9.-]*\.)?realvnc\.com/
    ^https?://([A-Za-z0-9.-]*\.)?services\.realvnc\.com/

    Or the below group

    ^https?://([A-Za-z0-9.-]*\.)?realvnc\.com/
    ^https?://([A-Za-z0-9.-]*\.)?services\.realvnc\.com/
    ^https?://([A-Za-z0-9.-]*\.)?hb-a\.services\.vnc\.com/
    ^https?://([A-Za-z0-9.-]*\.)?hb-b\.services\.vnc\.com/
    ^https?://([A-Za-z0-9.-]*\.)?hb-c\.services\.vnc\.com/

    Or the below group

    ^https?://[A-Za-z0-9.-]*\.realvnc\.com/
    ^https?://[A-Za-z0-9.-]*\.services\.realvnc\.com/
    ^https?://[A-Za-z0-9.-]*\.hb-a\.services\.vnc\.com/
    ^https?://[A-Za-z0-9.-]*\.hb-b\.services\.vnc\.com/
    ^https?://[A-Za-z0-9.-]*\.hb-c\.services\.vnc\.com/

    With either of these as my group of entries, using a browser to access the RealVNC site and the login page does bypass the Sophos UTM interception and I see the correct certificate details (but none of them fix the RealVNC Viewer login problem):

    https://www.realvnc.com/en/ shows as being Starfield
    https://manage.realvnc.com/ shows as being GeoTrust

    To me it looks like the RealVNC Viewer might be attempting to log into a different domain than the one's covered by the above exceptions (and indeed, a different domain to the one you use when logging in via a browser) and thus one that I haven't yet captured by of the above exceptions. Oddly though, the RealVNC logs (as per my first post) imply that it's cycling through the three services.vnc.com domains (which should be captured) and failing, so it is quite a mystery.

    I must again stress that I don't need this to work - all the machines I need access to are on internal VLANs and they all work without the RealVNC viewer being authenticated to RealVNC's site - but finding out how to debug the problem would certainly be useful for future such issues (and I would just really love to know what's going wrong). Time for a break, a fresh pot of coffee and some pondering to see if I can figure out how to look deeper into it all.

    The biggest puzzle to me is that I'd expect there are loads of people using RealVNC and Sophos UTM web filtering, so I'd have expected a web dredge to find lots of posts about it, but that doesn't seem to be the case, so it does make me think that I am doing something seriously stupid (and I will kick myself when I realise what it is) :-P .

    Kind regards,
    Briain
  • 0 in reply to Briain
    Hi Folks

    I have found a 'fix' for this. I am puzzled why it could not be solved via entering exceptions in the web filter (despite looking at the RealVNC logs to ensure all addresses were captured by the exceptions listed in my first post, and even resorting to Wireshark) but in the RealVNC client log file, it was indicating my certificate was being detected and that 'The certificate is not correctly signed by the trusted CA', so clearly the exceptions were not working. Anyhow, I noticed that in the RealVNC client settings, there is an option whereby you can tell RealVNC client to use a proxy, so for the server, I entered my Sophos UTM's hostname and port (so in my case, 'hadrian:443') and for the type, I selected 'HTTP CONNECT' and it worked a treat (RealVNC client immediately logged into my account and the RealVNC log files show everything is now working as it should).

    Hope that helps anyone else who comes across this issue (but if anyone knows why the exceptions didn't work, I would be most interested, just for my own learning).
    All the best
    Proxy Briain :-)
Reply
  • 0 in reply to Briain
    Hi Folks

    I have found a 'fix' for this. I am puzzled why it could not be solved via entering exceptions in the web filter (despite looking at the RealVNC logs to ensure all addresses were captured by the exceptions listed in my first post, and even resorting to Wireshark) but in the RealVNC client log file, it was indicating my certificate was being detected and that 'The certificate is not correctly signed by the trusted CA', so clearly the exceptions were not working. Anyhow, I noticed that in the RealVNC client settings, there is an option whereby you can tell RealVNC client to use a proxy, so for the server, I entered my Sophos UTM's hostname and port (so in my case, 'hadrian:443') and for the type, I selected 'HTTP CONNECT' and it worked a treat (RealVNC client immediately logged into my account and the RealVNC log files show everything is now working as it should).

    Hope that helps anyone else who comes across this issue (but if anyone knows why the exceptions didn't work, I would be most interested, just for my own learning).
    All the best
    Proxy Briain :-)
Children
  • 0 in reply to Briain
    One option would be to use a big exception, then to narrow it down.  Its a hacky solution and I wouldn't use it except as a last resort.
    .*vnc.*
    Then if that works try
    .*vnc\.com.*
    Then
    ^https?://.*vnc\.com
    and so on

    If it were me, I'd be using Wireshark.  What you really want to see is the SNI (Server Name Identification) that is part of the Hello.  Google Wireshark SNI.
    You can then double check - the server name in the SNI should resolve to the IP address that it is connecting to.
     
    If the RealVNC is connecting without setting an SNI - then there is the problem.  Without SNI the proxy cannot determine the destination site until after it has already done the MITM decryption, so the exception cannot be applied retroactively.
     
    Forcing the VNC client to use standard mode proxy is a solution as well.  That would allow the proxy to better see what the final site it is connecting to is, no SNI is needed.
     
    However...  by default the standard mode proxy is port 8080 (see Filtering Options, Misc tab).  Having it has 443 could be very problematic.  And if you have it set to 8080 in your UTM configuration, but RealVNC worked when connecting to 443...  Either you've got a weird setup with potential security holes, or RealVNC is doing something that we don't understand and probably isn't good.  In this configuration do you see the RealVNC traffic logged in the Web Proxy?
  • 0 in reply to Michael Dunn

    Dear Michael Dunn

    Many, many, many apologies for not spotting your reply until today. Due to me only requiring access to machines on my own sub-networks, I really had no need to sign into the RealVNC service (so I wasn't that bothered about it and thus just gave up trying to fix it) but it's been on the back of my mind that I should get around do digging deeper, so just yesterday, I decided to have another shot and the first thing I tried was adding the below two below exceptions...

    ^https?://[A-Za-z0-9.-]*\.vnc\.com/
    ^https?://[A-Za-z0-9.-]*\.realvnc\.com/

    ...to a small group, which was already configured as is shown below:

    Skipping: Sandstorm / URL Filter / Content Removal / SSL scanning

    When I then entered my credentials into the RealVNC client (on my Debian laptop) it immediately logged me into their server (and that was with no proxy information configured within the client; it was just set to the default of 'use the system proxy settings'). I thought I had tried something similar, back in the day, but perhaps I am mistaken (and of course, I have also updated the Debian RealVNC Viewer package, since then) but anyhow, I have now effectively done just as you had suggested and all is now well. This morning, I sought out this thread to add an update about resolving it and that was when I spotted your post.

    Anyhow, thank you very much indeed for responding, and also for informing me about SNI - I really do appreciate you taking the time to do so - as that is something with which I am currently unfamiliar with. As you had suggested, I will indeed go and search for 'Wireshark SNI' in order to find out what it is all about (and I'm already familiar with Wireshark, so I'll also try capturing it). It is always great to learn something new, so thank you once again for alerting me to its existence!

    Kind regards

    Briain

Unfiltered HTML