Is it that all protocols implemented on top of TCP/ UDP are supported by chrome? Does HTTP/ HTTPS implementation somehow hides functioning SMTP or FTP in the background ?
Do all browsers support ssh through them or is it a design thing?
In terms of what protocols you can use in the Chrome browser bar you can use: HTTP, HTTPS, FILE, and FTP. SSH is not implemented by Chrome, but rather it implements SSL. It also does not implement SMTP, but rather when you visit a website like Gmail or Yahoo mail, you are simply visiting a website (via HTTP or hopefully HTTPS). That website is not at all connecting to an SMTP server to display your emails, but is merely serving up web pages and connecting to API's to display/edit/compose your email (by then which the email client's backend is connected to their SMTP server).
Also chrome does implement FTP, like you can visit an IP address that has FTP enable such as : ftp://123.34.45.890 and you can use the directory listings as a webpage. An example of this would the CentOS mirrors here. On the right column they have FTP sites. You can access the FTP director via web browser that supports FTP or you can fire up a terminal and do ftp ftp://ftp.is.co.za/mirror/centos/.
For the ssh part,Google chrome supports SSL and not ssh. Though ssh can be done using extensions like secure-shell. These extensions combines the ssh command (see http://openssh.org/ for details) ported to NativeClient with the “hterm” terminal emulator to provide a secure shell client for the Chrome browser.
Though a key thing to be noted is that “HTML Terminal”, or hterm, is an xterm-compatible terminal emulator written entirely in JavaScript.
It is intended to be fast enough and correct enough to compete with native terminals such as xterm, gnome-terminal, konsole and Terminal.app.
hterm is only a terminal emulator. It does not provide SSH access (or any other text-based command) on its own.
The 4 main protocols are HTTP, HTTPS, FILE, FTP. All other protocols are designed to work on top of them.
For the second part, all browsers can be made to support ssh through them.
Related
In my particular network environment the Google chrome executable can access via an authenticated outgoing proxy server external web sites. Other executables however (when pointing to that outgoing proxy) are not able to do so.
I now have the idea to use Chrome itself as a local proxy for other executables like git or pip. - Is this possible, say, with a Chrome extension or with a tool that uses Chrome in a headless mode to connect to the Internet?
To clarify, I am not asking how to configure the proxy settings inside Chrome - I have successfully done this. I am asking how I can set up Chrome to receive HTTP(S) requests from other local programs and pass the requests on as an intermediate proxy (to the outgoing proxy specified in Chrome's settings).
On its own, no: Chrome will not open a port that other software can connect to. Even WebRTC requires an intermediate server to begin a peer to peer connection between browsers.
However Chrome supports Native Messaging, which means it will execute a specific native application that already exists on the system.
With this set up you can have:
a native application that accepts incoming connections and forwards data to the extension.
the extension listens to messages from the application and sends them via Chrome elsewhere on the internet.
I am hosting my page inside the sdcard of arduino, I have implemented web speech api feature in that, however when I test my site using 127.0.0.1/project-X , everything works perfect, but when I use 192.168.1.4(which is same machine) or 192.168.1.10 (which is other laptop having WAMP) Chrome does not allow the microphone? I have also tried to start Chrome using different flags found on Google but none of them worked. What to do? I just want Chrome to allow using microphone from local ip also!
Chrome now allows Microphone access over secured Http only. You can very easily create your own signed SSL certificate and use that to host your page via Https.In tomcat server.xml you just have to un-comment the ssl connector and point to the location of your certificate.
I'd like to make an SSH-based extension for Chrome, but I can't figure out how the secure shell extension is able to access raw sockets in Chrome.
It only has these permissions:
Yet I'm able to connect on port 22 via SSH. I know it uses PNaCl through Enscripten, but how do these provide raw socket access?
Has Google hard-coded whitelabel permission to the sockets API just for this extension?
Secure Shell gets access to raw sockets via (P)NaCl because it has been whitelisted in the Chromium source. ugly, i know.
https://chromium.googlesource.com/apps/libapps/+/master/nassh/doc/hack.md#Whitelisted-Permissions
if you want to do raw sockets in your own Chrome app, you can do so via JavaScript:
https://developer.chrome.com/apps/socket
if you want to access raw sockets from Chrome extensions, or via a PWA, then currently you won't be able to do so. those only have access to WebSockets currently (which is basically HTTP). this is why projects like WebSockify exist.
if you check the manifest, you will see that it has this permission "terminalPrivate".
Then if you poke alittle bit around you will find those posts:
http://chromium.2324630.n4.nabble.com/crx-Use-chrome-terminalPrivate-API-in-chromeOS-extension-app-td17265.html
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-hterm/PtR2q2p_vss
The "good" comments you find on those sites are:
chrome.terminalPrivate exists, but it's native code only available to
the Secure Shell chrome extension, and only on Chrome OS.
Or this one:
chrome.xPrivate APIs are, well, private APIs that are only used by
certain Chrome or Google extensions and applications.
Our setup is like this: we use a coldfusion 10 server, and files are on a local intranet. Users use a domain login to access any files over https. I'm interested in using html5 websockets, but the first attempt gave me an error because no credentials were supplied. Is there a way around this? If not, is there a recommended technology for this scenario?
The user does log in on the client side. If it's possible, what I'd really like to do here is pass those credentials when making the connection to the server.
you should be able to supply the authentication header to your web socket server before the elevation to web socket read that and send it back in the headers for the elevation (first frame) then when the browser connects it should have the authentication it needs.
if your using a custom authentication E.G in page not authentication header you can also do this by passing any custom header to your server.
Or mandate that the first thing your web client sends is the authentication details this could be something like {username_hash}.{password_hash} if they don't close the socket to them.
Do not do this.
You're now responsible for sending and encrypting the authentication credentials yourself, bypassing something that already works and is tested.
Anyone can snoop on an unencrypted websocket port. Use HTTPs for an intranet, use stable solutions, don't reinvent this wheel because it tickles your fancy.
In a couple of years some colleague will have to maintain this and will have to figure out how your homebrew version works versus something that's solid like plain browser authentication.
My advice: Leave this to the browser and to well-tested coldfusion libraries.
How do you tell if a site is an HTTP:// site or an HTTPS:// site? I am just starting to learn some of the more fundamental things about internet security. When you put up a web site is there a special way that you have to set up the html format in the .html files so that the site is secure or is this something that can be purchased from the site provider were you host the web site.
This seems like and easy thing to do but even on stackoverflow what it type in is
stackoverflow.com/questions/ask
There is no HTTP or HTTPS in front of the internet address. Is this implied or is there a way to toggle this on an off in the tools?
HTML Code:
<html lang="en">
<head>
<title>Test Title</title>
</head>
<body>
//...code goes here...
</body>
</html>
Is there something that goes in the HTML that determines whether the site is secure or not? Or is this an option on each page when you host the site.
How do you tell if a site is an HTTP:// site or an HTTPS:// site?
By looking at the URL
This seems like and easy thing to do but even on stackoverflow what it type in is
If you type in something that looks like a URL with the scheme missing, then browsers will assume you intended to put http:// in front of it.
Most browsers will hide the http:// part from the address bar for non-SSL sites.
When you put up a web site is there a special way that you have to set up the html format in the .html files so that the site is secure or is this something that can be purchased from the site provider were you host the web site.
To use SSL you need to have an SSL certificate and the web server needs to be configured to use it.
Beyond that, everything comes down to how the server is configured. You could have different sites hosted on http and https, or the same site, or redirect from one to the other, and so on.
Is there something that goes in the HTML that determines whether the site is secure or not?
No. SSL is dealt with at the transport level, not the document level.
Or is this an option on each page when you host the site.
You could configure a server to redirect the URLs for some pages to HTTPS and some to HTTP. This was typically done to save on CPU power for pages where security wasn't needed. Today, CPU power is much cheaper, so it is normally better to use SSL by default.
To make a site secured (an HTTPS) site you need a certificate and add the proper binding that means including a port and protocol by default https uses port 443 and NO, none of those configurations at server level will affect the files serve like your .html files.
HTTP means Hypertext Transfer Protocol. The "S" is Secure.
There is no special definition you can define to ensure a secure HTTP connection.
SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral.
These certificates can be purchased from companies that provide them. This essentially encrypts any data transferred between the server and person it is responding to.
In short, this is determined by the browser, and different browsers have different strategies.
When you visit a site, such as www.abc.com, different browsers will use different default protocols.
Microsoft Edge will first use http to connect to port 80 of the server. If the server is set to redirect, it will send a 301 move permanently message to allow the client to reconnect to the site using https.
But the new version of chrome will directly use https to connect to the site (port 443), if the connection fails, then connect to http (port 80).
https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html
Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol. HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.